После миграции URL используйте единую таблицу соответствия старых и новых URL, чтобы обновить общедоступные ссылки, объявления канонических URL, перенаправления и записи в файле Sitemap. В этом сценарии для настольного Mac показано, как согласовать эти изменения и проверить опубликованный результат.

Здесь рассматривается небольшая подборка общедоступных HTML-документов, которые переносятся по новым путям на том же сайте. Все примеры адресов и названий страниц вымышлены. Чтобы выполнить весь процесс, вам понадобится доступ к системе публикации, настройкам перенаправлений и соответствующему ресурсу Search Console.

Что должно совпадать после миграции?

Для каждого перемещённого документа выберите один конечный адрес. Контролируемые вами ссылки должны вести непосредственно на него, целевая страница должна указывать себя как каноническую, а в актуальном файле Sitemap должен быть указан этот адрес. Старый адрес должен перенаправлять на новый. Google считает перенаправления и аннотации canonical сильными сигналами канонизации, а включение в файл Sitemap — более слабым сигналом. Эти методы могут усиливать друг друга, но окончательный выбор канонической страницы делает Google. Рекомендации Google по канонизации.

У этих механизмов разные задачи. Перенаправление обрабатывает запрос к старому адресу. Общедоступная ссылка определяет, куда перейдёт читатель. Объявление canonical указывает предпочтительный URL документа; WHATWG определяет это значение для типа ссылки canonical. Файл Sitemap содержит список предпочтительных URL для обнаружения. Обновление одного из них не меняет остальные. Стандарт WHATWG HTML: тип ссылки canonical, рекомендации Google по файлам Sitemap.

Используйте эту таблицу соответствий как практическую проверку результата. Это рабочий процесс, выведенный из документации, а не система оценки Google.

Элемент Ожидаемый результат для вымышленного документа Colors
Старый адрес https://example.com/notes/colors.html постоянно перенаправляет на целевой адрес
Целевой адрес https://example.com/library/colors/ предоставляет документ Colors
Навигация и ссылки в документах Ведут непосредственно на https://example.com/library/colors/
Canonical целевой страницы Указывает https://example.com/library/colors/
Запись в актуальном файле Sitemap Содержит https://example.com/library/colors/

Составьте единую таблицу соответствий до изменения отдельных настроек

На Mac откройте электронную таблицу или текстовый редактор и запишите каждый старый адрес рядом с предполагаемым целевым. Google рекомендует подготовить таблицу соответствия старых и новых URL при переносе сайта. Сохраните копию исходного списка, чтобы при замене записей в файле Sitemap не потерять перечень адресов, для которых ещё нужно настроить перенаправления. Рекомендации Google по переносу сайта.

Документ Старый путь Конечный путь
Colors /notes/colors.html /library/colors/
Palette /notes/palette.html /library/palette/
Shapes /notes/shapes.html /library/shapes/

Для каждой строки укажите места, где нужно внести изменения: редактор страницы, общая навигация, настройка canonical, настройка перенаправлений и генератор файла Sitemap. Добавьте отдельные столбцы для проверки общедоступного ответа и инспекции в Search Console. Так расплывчатое указание «обновить URL» превращается в конечный список правок и проверок.

Перед утверждением таблицы проверьте содержимое целевых страниц. Если два старых документа объединены в один полезный документ, оба адреса могут перенаправлять на него. Не перенаправляйте несвязанные документы на главную страницу: Google предупреждает, что нерелевантные перенаправления могут считаться soft 404. Рекомендации Google по сопоставлению перенаправлений.

Обновите общедоступные ссылки и проверьте относительные пути

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

Изменение пути может повлиять на назначение относительной ссылки, даже если её текст остался прежним. Стандарт WHATWG URL определяет разрешение относительных ссылок относительно базового URL. В примерах ниже предполагается, что документ не содержит явного переопределения базового URL. Стандарт WHATWG URL.

URL документа Значение ссылки Разрешённый адрес
https://example.com/notes/colors.html palette.html https://example.com/notes/palette.html
https://example.com/library/colors/ palette.html https://example.com/library/colors/palette.html
https://example.com/library/colors/ /library/palette/ https://example.com/library/palette/

Эти вымышленные адреса проверены с помощью API JavaScript URL. Неизменённое значение palette.html теперь указывает внутрь каталога Colors, поэтому успешная замена текста в другом месте не обнаружит проблему. Для этой небольшой подборки использование нужного пути от корня явно задаёт адрес назначения. При переносе на другой хост укажите правильный абсолютный адрес или проверьте, что каждая ссылка от корня по-прежнему ведёт на нужный хост.

Откройте опубликованный документ Colors в браузере на Mac и перейдите по ссылке Palette. Проверьте и отображаемый документ, и конечный адрес. Повторите проверку для общей навигации и ссылок на разделы. Если ссылка содержит #swatches, убедитесь, что на целевой странице по-прежнему есть соответствующий идентификатор раздела: одной таблицы путей для этого недостаточно.

Настройте canonical и постоянные перенаправления в их источнике

Для каждого нового HTML-документа задайте canonical, равный конечному абсолютному URL. Google рекомендует абсолютные канонические URL и принимает элемент canonical в HTML в head документа. Если в системе публикации есть поле canonical, введите туда адрес и проверьте сгенерированный результат. Инструкции Google по настройке canonical.

Для страницы Colors ниже приведён фрагмент метаданных, который нужно поместить в существующий раздел head документа. Это не полный HTML-документ:

<link rel="canonical" href="https://example.com/library/colors/">

Проверьте, не отправляет ли хост canonical также в заголовке HTTP-ответа Link. Google поддерживает оба метода, но рекомендует выбрать один, поскольку при использовании обоих могут возникнуть противоречивые адреса назначения. Исправьте шаблон или настройку, которые формируют это значение, чтобы при следующей публикации не восстановился старый адрес. Способы канонизации Google.

Настройте старый адрес так, чтобы сервер постоянно перенаправлял его на целевой. RFC 9110 определяет 301 и 308 как постоянные перенаправления и описывает адрес назначения в заголовке Location. Они различаются обработкой метода запроса: 308 сохраняет метод, тогда как 301 допускает историческое преобразование POST в GET. Для обычной загрузки документов Google рассматривает оба варианта как сигналы постоянного перенаправления. RFC 9110: семантика HTTP, документация Google о перенаправлениях.

Точная настройка зависит от вашего хостинга или системы публикации. Одно лишь редактирование в браузере не может создать правило HTTP-ответа. Если платформа не позволяет настраивать серверные перенаправления, воспользуйтесь документированной конфигурацией хостинга или попросите оператора хостинга реализовать таблицу соответствий. Google описывает мгновенное перенаправление через meta refresh как запасной вариант, если серверные перенаправления недоступны; перенаправления JavaScript рекомендуются только тогда, когда нельзя использовать другие способы. Одно объявление canonical не перенаправляет посетителя на новый адрес. Поддерживаемые Google способы перенаправления.

Сгенерируйте файл Sitemap на основе тех же целевых адресов

Обновите источник файла Sitemap, а затем сгенерируйте его заново. Ручную правку сгенерированного файла легко потерять при следующей сборке. После этой миграции в актуальном файле Sitemap должны быть конечные URL страниц Colors, Palette и Shapes, а не их старые пути.

Google требует указывать в файлах Sitemap полностью определённые абсолютные URL и использовать кодировку UTF-8. Если нужно перечислить только веб-страницы, можно использовать текстовый файл Sitemap: по одному URL в строке, без заголовков и пояснений. Полный вымышленный пример для трёх страниц:

https://example.com/library/colors/
https://example.com/library/palette/
https://example.com/library/shapes/

Форматы файлов Sitemap и требования Google.

Если сайт уже формирует XML-файл Sitemap, сохраните этот поддерживаемый формат и обновите записи URL. Указывайте точные даты изменения, если передаёте lastmod: Google говорит, что это значение должно отражать существенные обновления страницы. Не меняйте все даты автоматически только ради того, чтобы файл Sitemap выглядел свежим. Рекомендации Google по XML-файлам Sitemap.

Проверьте общедоступный результат на Mac

Проверьте опубликованный результат, поскольку предварительный просмотр в редакторе не подтверждает HTTP-ответ по общедоступному адресу. Откройте Terminal на Mac. В приведённых ниже диагностических командах используются вымышленные адреса: перед запуском замените их соответствующими общедоступными URL из своей таблицы. Эти примеры не означают, что проверялась реальная миграция.

old_url='https://example.com/notes/colors.html'
new_url='https://example.com/library/colors/'

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  --dump-header - --output /dev/null "$old_url"

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  --location --max-redirs 5 --output /dev/null \
  --write-out 'status=%{http_code}\nfinal=%{url_effective}\nredirects=%{num_redirects}\n' \
  "$old_url"

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  "$new_url"

Первая команда выводит заголовки исходного ответа, не переходя по перенаправлению. Вторая следует перенаправлениям и сообщает конечный статус, адрес и число перенаправлений. Третья загружает разметку целевой страницы для проверки. Описание этих параметров приведено в руководстве curl.

Для обычной страницы с соответствием ожидайте в исходном ответе 301 или 308 с нужным значением Location, после чего документ должен успешно открыться по конечному адресу. Проверьте canonical в полученной разметке. Также просмотрите документ в браузере: успешный HTTP-ответ сам по себе не доказывает, что было загружено нужное содержимое. Google рекомендует перенаправлять сразу на конечный адрес, не создавая цепочки. RFC 9110: коды состояния, рекомендации Google по переносу сайта.

Если строка не проходит проверку, используйте следующий порядок диагностики. Он связывает исправления с наблюдаемым результатом.

Наблюдение Следующее действие
Старый URL перенаправляет на неверную страницу Исправьте соответствие или правило перенаправления
Перенаправление ведёт ещё на одно перенаправление Настройте прямой переход со старого адреса на конечный
У правильной страницы указан старый canonical Исправьте источник метаданных и опубликуйте страницу заново
Навигация по-прежнему ведёт на старый путь Обновите исходную ссылку или общий шаблон
В файле Sitemap по-прежнему указаны старые пути Исправьте входные данные генератора и создайте файл заново
Terminal сообщает о тайм-ауте Повторите проверку после устранения проблемы с подключением; отметьте тест как незавершённый

Отправьте файл Sitemap и отличайте текущие проверки от индексации

В Search Console выберите ресурс, охватывающий новые URL, и отправьте общедоступный адрес файла Sitemap через отчёт Sitemaps. Google указывает этот отчёт как способ отправки; в нём также отображаются ошибки обработки. Отправка помогает обнаружить страницы, но не гарантирует их индексацию. Инструкции Google по отправке файла Sitemap.

Чтобы проверить новый документ, введите его полный URL в строке проверки Search Console. Используйте проверку опубликованного URL, чтобы выяснить, доступен ли он сейчас и может ли быть проиндексирован. Чтобы узнать, какой canonical выбрал Google, откройте результат индексации и поле Google-selected canonical. Проверка опубликованного URL не позволяет предсказать выбор канонической страницы. Инструмент проверки URL в Search Console.

В этом примере пути меняются в пределах одного хоста, поэтому инструмент Change of Address неприменим. Google рекомендует издателям, меняющим пути, настроить перенаправления и обновить файлы Sitemap. Этот инструмент предназначен для переноса домена или поддомена после переезда сайта и настройки перенаправлений. Инструмент Change of Address в Search Console.

Сохраните таблицу соответствий как журнал обслуживания. Отмечайте строку выполненной, только когда общедоступное перенаправление, содержимое целевой страницы, ссылки, canonical и файл Sitemap согласованы; последующие наблюдения об индексации Google записывайте отдельно. По возможности сохраняйте перенаправления как можно дольше: в общих рекомендациях Google по миграции говорится о сроке не менее одного года. В будущих изменениях документов продолжайте использовать конечные адреса. Рекомендации Google по миграции.

Источники