Як усунути дублі зі слешем, регістром і www

Адреси зі слешем і без нього, з www і без нього, а також шляхи в різному регістрі іноді відкривають один документ. Але зовнішня схожість не доводить, що це копії: сервер може розрізняти /Catalog/ і /catalog/, а перенаправлення одного варіанта на інший не створює другу HTML-копію.

Спочатку збережіть фактичні відповіді та порівняйте вміст. Потім виберіть основну адресу для підтверджених копій, погодьте обробку решти варіантів і перевірте повний маршрут. Масове приведення всіх шляхів до нижнього регістру без перевірки здатне зламати окремі сторінки та файли.

Зберіть варіанти та їхню фактичну поведінку

Візьміть адреси з CMS, внутрішніх посилань, sitemap, доступних журналів і Search Console. Збережіть повні початкові URL разом із протоколом, хостом, регістром шляху, завершальним слешем і параметрами. Укажіть джерело кожного рядка: воно допоможе знайти шаблон, який продовжує створювати старий варіант.

Для контрольних сторінок різних типів перевірте першу HTTP-відповідь, заголовок Location, наступні переходи та кінцевий документ. Запишіть canonical кінцевої HTML-сторінки й порівняйте вміст. Відповідь 200 показує успішне отримання відповіді, але сама по собі не доводить, що дві сторінки однакові або доступні для індексації.

Припустімо, умовний магазин вибирає https://example.com/catalog/ для основного каталогу. У його системі /Catalog/ є іншим розділом і має залишатися самостійним. Нижче показано очікувані результати після погодженого налаштування, а не результати тесту реального сайту.

Останній рядок – навмисний виняток: вміст двох шляхів у прикладі відрізняється. Кількість переходів рахують від зазначеного початкового URL до кінцевої відповіді. На іншому сайті фактичні статуси та правила можуть відрізнятися.

Виберіть хост і протокол

Перевірте, які адреси реально використовуються сайтом, відвідувачами та інтеграціями. Для доступної захищеної версії зазвичай погоджують HTTPS і один бажаний хост: з www або без нього. Хости різні. Під час вибору врахуйте чинні посилання, рекламу, сертифікати, налаштування сайту та план перенесення.

У прикладі обидві версії хоста обслуговують один каталог, тому варіант із www спрямовують на відповідний шлях без нього. Не переносіть це рішення на інший піддомен автоматично: shop.example.com іноді обслуговує самостійний сайт. Ціль переходу має зберігати потрібну сторінку й мову, а не завжди вести на головну.

Перевірте TLS-сертифікат і доступність кожного HTTPS-хоста, з якого передбачається перенаправлення. Браузер встановлює захищене з’єднання до отримання HTTP-відповіді: помилка сертифіката виникає до отримання редиректу. Перехід з HTTP на HTTPS також перевіряють за початковою відповіддю з урахуванням можливого автоматичного переходу браузера.

Розрізняйте регістр хоста та регістр шляху

Ім’я хоста в URL не чутливе до регістру: EXAMPLE.com і example.com позначають той самий хост. Це не означає, що www.example.com і example.com збігаються: наявність www змінює ім’я хоста.

Для шляху загального правила про нечутливість до регістру немає. Поведінка залежить від маршрутизації, сервера та застосунку: /Catalog/ і /catalog/ можуть відкривати один документ, різні документи або помилку. Перевірте наявні сторінки й файли до впровадження загального правила. У прикладі їхній вміст відрізняється, тому об’єднання знищило б доступ до окремого розділу.

Для нових сторінок команда має право вибрати єдиний регістр написання, якщо це підтримується системою. Для старих шляхів спочатку складіть список винятків, зокрема зображень, інструкцій, файлів для завантаження та інтеграцій. Не перетворюйте автоматично значення параметрів та ідентифікатори: регістр усередині них буває значущим для застосунку.

Перевірте завершальний слеш для кожного типу ресурсу

Адреси /catalog і /catalog/ – різні варіанти шляху. У нашому прикладі вони стосуються одного розділу, і вибрано другий. Якщо обидва повертають 200, порівняйте вміст, функції та призначення до рішення про перенаправлення. Якщо один уже віддає 301 на інший, це маршрут до сторінки, а не дві окремо видані HTML-копії.

Правило для розділів не переноситься без перевірки на файли та API: додавання слеша до /manual.pdf змінює запитуваний шлях. Для кореня хоста браузер зазвичай представляє порожній шлях як /; відмінність між виглядом https://example.com і https://example.com/ в адресному рядку не доводить наявності двох окремих сторінок.

Погодьте перенаправлення та canonical

Для непотрібної копії, яку вирішено остаточно замінити, розгляньте постійне серверне перенаправлення, наприклад 301 або 308. Якщо обидві версії мають залишатися доступними, для однакового вмісту окремо оцінюють canonical. Це різні механізми: редирект переводить запит на іншу адресу, а canonical позначає бажаного представника для пошуку.

На кінцевій сторінці перевірте, що власний canonical, внутрішні посилання та записи в актуальній sitemap узгоджені з прийнятим рішенням. Google самостійно вибирає канонічний URL; значення в HTML і вибір пошукової системи перевіряють окремо. Покрокову перевірку описано в матеріалі про налаштування rel canonical.

Не використовуйте noindex або заборону обходу як автоматичну заміну перевірці маршруту. Якщо пошуковий робот не отримує відповідь сторінки, він не прочитає вказівки в її HTML і заголовках. Різні мовні версії та різні документи також не можна вважати копіями лише через схожий шаблон.

Не допустіть конфлікту правил

Пройдіть маршрут цілком. Два правила іноді конфліктують: одне додає слеш, інше видаляє його; у результаті запит повертається на початкову адресу. Аналогічний цикл виникає за протилежних правил для хоста або протоколу. До запуску порівняйте пріоритети правил на сервері, CDN і в застосунку, а не лише кожне налаштування окремо.

За можливості спрямовуйте старий URL безпосередньо до погодженої кінцевої сторінки. Якщо технічні або захисні обмеження вимагають проміжного кроку, зафіксуйте причину та перевірте весь ланцюжок. На кожному кроці мають зберігатися потрібні параметри, вибрана мова та призначення ресурсу; параметри кампанії й параметри вибору товару не можна видаляти однаковим правилом без аналізу.

Перевірте GET-запити, потрібні застосунку методи та винятки в тестовому середовищі, потім на погодженій вибірці після випуску. До змін збережіть конфігурацію та визначте, за яких помилок команда зупинить впровадження й поверне попередню поведінку. Не копіюйте без адаптації правило для одного серверного середовища до іншого.

Перевірте результат на внутрішніх посиланнях

1. Для звичайної сторінки, категорії, товару й файла збережіть початковий URL, кожну відповідь і підсумкову адресу. Включіть обидві мови, якщо вони є.
2. Перевірте варіанти протоколу, хоста, слеша та регістру, а також поєднання кількох відмінностей. Для /Catalog/ у прикладі переконайтеся, що окремий розділ зберігся.
3. Порівняйте кінцевий документ з очікуваним, потім перевірте canonical і потрібні параметри. Ланцюжок до 200 не підтверджує, що відкрилася правильна сторінка.
4. Виправте джерела старих посилань у меню, шаблонах, хлібних крихтах і sitemap. Перевірте їх повторно: редирект, що працює, сам не змінює початкові посилання.
5. Окремо вивчіть дані Google після змін. Успішна технічна перевірка не доводить вибір канонічної адреси, фактичну індексацію або зростання трафіку.

Пошук інших різновидів повторів, зокрема параметрів і вмісту різних сторінок, описано в статті про технічні дублі сайту. Отримана матриця допомагає зберегти потрібні ресурси та виправити саме ті варіанти, які справді стосуються однієї сторінки.