Слеш в конце URL: как убрать дубли без потери страниц

Когда слеш создает две копии HTML

Мини-кейс: ссылка на изображение записана как src="images/schema.svg". На /services/seo/ она может разрешиться относительно каталога, а на /services/seo - относительно корня /services/. Если один из адресов пока отдает 200, одинаковый HTML фактически показывает разные ресурсы. Используйте надежные абсолютные пути для критичных файлов и выберите единый формат HTML-URL. До запуска массового редиректа проверьте /api/, PDF и параметры, которые сервер обрабатывает иначе. После выпуска откройте оба варианта напрямую, а не только переходом из меню, чтобы увидеть настоящий конечный ответ. Отдельно пройдите ссылку на страницу из старой рассылки: редирект обязан сохранить понятный маршрут и не терять параметры, которые нужны для измерения перехода.

Относительная ссылка images/logo.svg по-разному разрешается на /services/seo и /services/seo/, поэтому ошибку может заметить посетитель раньше поискового отчета. Не объединяйте правила для HTML и /guide.pdf/: добавление слеша к файлу часто означает другой, несуществующий путь. Зафиксируйте исключения для API и файлов, затем протестируйте параметры запроса и прямой переход со старой закладки.

Проверьте пары URL и файлы

Проверьте пары URL на нескольких уровнях: корень, услуга, статья, файл. Зафиксируйте HTTP, Location, canonical, внутреннюю ссылку и загрузку ресурсов.

Не переносите правило страниц на файлы механически: /guide.pdf и /guide.pdf/ не обязаны означать одно и то же. Учтите особенности фреймворка и сервера.

Сверьте canonical и относительные ресурсы

Сам по себе слеш не повышает и не понижает качество страницы. Проблема возникает, когда две доступные копии и противоречивые ссылки создают неоднозначность.

Выберите постоянный формат страниц

Выберите один формат для HTML-страниц и настройте прямой редирект с альтернативы. Внутренние ссылки, sitemap и canonical должны вести на выбранный конечный 200.

Разные пути могут действительно вести к разным ресурсам в конкретном приложении. Перед массовым правилом проверьте реальные маршруты и API.

Выберите один формат для HTML и отдельно пропишите исключения для файлов и API. Если обе версии страницы отдают 200, сравните содержимое и canonical; если одна перенаправляет, проверьте путь без лишней ступени. Не добавляйте слеш к PDF механическим правилом.

Направьте альтернативу без цепочки

Проверьте обработку query-параметров и якорей при переходе. Редирект не должен отбрасывать полезное состояние страницы или строить петлю.

Откройте оба адреса после релиза

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

Проверьте пары /service и /service/, а также /guide.pdf и URL с параметром. В каждой паре запишите код, Location, canonical и загрузку относительных ресурсов. Внутреннее меню и sitemap должны ссылаться сразу на принятый вариант HTML.

Проверка результата

• Намерение страницы определено
• Сохранена выборка URL до исправления
• HTTP-ответ и содержимое сверены
• Внутренние ссылки проверены
• Исключения учтены
• Проверка после релиза записана

Скачать таблицу примера

Вопросы по теме

Читайте также