После смены домена сверь три адреса для каждой важной страницы: URL в новой sitemap, конечный адрес после перехода со старого URL и canonical в HTML новой страницы. В согласованном варианте эти сигналы указывают на соответствующую страницу нового домена. Если они расходятся, сначала выясни, какой адрес должен быть основным, исправь подтверждённую ошибку и повтори ту же проверку.
Кратко
- Составь постраничную карту старых адресов и их целевых страниц на новом домене.
- Запиши фактический ответ сервера и конечный URL после перехода со старого адреса.
- Сверь canonical в HTML новой страницы с выбранной предпочтительной версией.
- Оставь в новой sitemap канонические адреса нового домена без старых и альтернативных версий.
- После правки снова сравни переход, canonical и sitemap для каждой проверяемой страницы.
Составьте карту соответствий старых и новых страниц
Начни с таблицы, где у каждого старого адреса есть конкретная целевая страница на новом домене. Такая карта нужна не для отчётности: по ней ты поймёшь, куда должен вести старый URL и с каким адресом сравнивать canonical и sitemap.
Какие страницы включить? Выбери те адреса, которые важно проверить при переезде: например, значимые страницы каталога или разделов. Это рабочий набор для сверки, а не универсальная выборка. Готового правила, сколько URL брать и как определить размер списка, в переданных материалах нет. Поэтому не выдавай произвольное количество страниц за норму.
Для первого этапа проще сохранить пути страниц, если это соответствует плану переезда. Тогда соответствия легче записать: старый адрес раздела сопоставляется с новым адресом того же раздела. Если меняются и домен, и структура сайта, путь уже нельзя считать автоматически подходящим. Для такого случая назначь каждой старой странице отдельную целевую страницу; не подменяй карту предположением, что адреса совпадают.
В таблице достаточно четырёх колонок:
| Старый URL | Целевой URL на новом домене | Фактический конечный URL | Примечание |
|---|---|---|---|
https://old.example/catalog/x | https://new.example/catalog/x | заполнить после проверки | совпадает или требует разбора |
Первые две колонки — план. Третью заполняй только после фактической проверки перехода, а не копируй туда целевой адрес из плана. Если целевая страница изменилась, зафиксируй это отдельно: иначе позднее будет неясно, сравниваешь ли ты результат с актуальным соответствием.
На этом этапе не делай выводов об успешной индексации. Карта отвечает на более узкий вопрос: какой новый адрес должен соответствовать каждому старому? Дальше проверь, куда старый URL действительно приводит.
Canonical URL: как поставить правильно и не потерять страницы из индекса→Проверьте конечный адрес и ответ для каждой старой страницы
Открой каждый старый URL из карты и запиши две вещи: фактический ответ сервера и конечный адрес после перехода. Затем сравни конечный URL с запланированным целевым адресом. Так проверка показывает не только то, что старый адрес куда-то ведёт, но и совпадает ли результат с твоей картой.
Зачем записывать обе величины? Сам по себе адрес в браузере после перехода не объясняет весь путь. А запись конечного URL без фактического ответа оставляет пробел: ты не фиксируешь, какой ответ получил исходный адрес. Для постраничной сверки полезны исходный URL, фактический ответ, конечный URL и целевой адрес из карты.
Сравни путь с тем, что ты запланировал. Если старый URL ведёт сразу на соответствующую страницу нового домена, результат совпадает с картой. Для постоянного переноса используй серверный ответ 301 или 308 и записывай фактический статус вместе с конечным URL. Google рекомендует направлять старый URL сразу на конечный адрес и избегать цепочек. Если одновременно меняются домен и пути, рекомендации Google и Яндекса различаются: Яндекс описывает переход через прежний путь на новом домене. В таком случае не применяй совет об отсутствии промежуточного адреса без учёта этой разницы. После проверки сравни конечный URL с назначенной целью и отметь цепочку, если она есть.
Не заменяй целевой URL главной страницей только потому, что исходный путь не открывается или точное соответствие неочевидно. Сначала определи, какая страница действительно соответствует старой. Если релевантной замены для удалённой страницы нет, не перенаправляй её на главную или случайную категорию: верни ответ 404 или 410. Зафиксируй это решение в карте вместо догадки о целевой странице.
Что считать результатом проверки? Строку, где видно, какой адрес проверялся, какой ответ получен, куда он привёл и совпал ли итог с назначенной целью. Такая запись пригодится и при повторной проверке после исправления: сравнивать нужно те же поля, а не общее впечатление от работы сайта.
Alternate page with proper canonical: когда это норма, а когда — ошибка→Сверьте canonical новой страницы с её конечным адресом
На каждой целевой странице найди canonical в HTML и сравни указанный там URL с выбранной предпочтительной страницей на новом домене. Для новых индексируемых страниц рекомендуется self-referencing canonical: адрес указывает на саму страницу. Но этот сигнал не заменяет переход со старого URL. Проверяй оба механизма отдельно.
Здесь важна точность соответствия. Если в карте для старого адреса назначена страница https://new.example/catalog/x, открой именно её HTML и запиши значение canonical. Сопоставь его с URL этой целевой страницы. Не ограничивайся проверкой домена: полный адрес может различаться путём или версией URL.
Какие сведения стоит занести в таблицу? Минимум — целевой URL, фактическое значение canonical и результат сравнения. Если canonical указывает на другой адрес, сначала выясни, является ли тот адрес намеренно выбранной предпочтительной версией. Не исправляй тег только потому, что он отличается от ожидаемого: сначала подтверди, какой URL должен быть основным для этой страницы.
Canonical сообщает предпочтительный адрес среди версий страницы, но не выполняет перенаправление. Поэтому старый URL всё равно проверяется отдельно: наличие правильного canonical на новой странице не доказывает, что прежний адрес ведёт к ней. И наоборот, правильный переход не подтверждает, что HTML новой страницы указывает на нужный canonical.
Не делай безусловных выводов о том, как поисковая система учтёт canonical в каждом частном случае. Переданные фрагменты не задают полного правила для всех ситуаций. Практическая задача уже и проверяема: записать значение из HTML, сопоставить его с выбранной новой страницей и отметить расхождение для дальнейшего разбора.
Очистите sitemap от адресов старого домена и дублей
В новую sitemap включай только страницы нового домена, которые выбраны каноническими и должны индексироваться. Просмотри записи и отдельно отметь старый домен, тестовые поддомены, staging-адреса и URL с рекламными метками. Затем сравни каждую нужную запись с картой соответствий и canonical целевой страницы.
Где искать неправильные варианты? Проверь сами адреса в файле карты: домен, путь и возможные версии одной страницы. Если одна страница представлена несколькими адресами, оставь в новой карте ту версию, которую выбрал как каноническую. Для проверки достаточно зафиксировать URL из sitemap и рядом — целевую страницу из карты; дальше свести результаты с переходом и canonical.
Не используй sitemap как проверку статуса индексации: в этой задаче ты фиксируешь состав файла и сверяешь адреса после переезда, а не устанавливаешь, включена ли страница в индекс или видна ли она в поиске.
Если найдёшь старый домен или альтернативную версию, сначала проверь, относится ли запись к нужной странице и какой адрес выбран основным. Удаляй подтверждённо лишний адрес из новой карты, а не все URL, которые выглядят непривычно. Переданные материалы не описывают конкретные действия в панели управления или CMS.
После изменения снова просмотри записи карты. Убедись, что исправленный URL соответствует целевой странице нового домена и не осталась другая запись с альтернативным адресом той же страницы. Затем добавь результат в общую постраничную сверку. Так можно увидеть, согласуется ли sitemap с фактическим переходом и canonical, а не проверять карту изолированно.
Сопоставьте адреса в sitemap, canonical и переходах
Для каждой страницы собери три значения в одной строке: адрес из новой sitemap, конечный URL после перехода со старого адреса и canonical из HTML целевой страницы. Если все они соответствуют выбранной предпочтительной странице нового домена, адресные сигналы не противоречат друг другу в этой проверке.
Именно постраничная строка помогает не спутать разные ситуации. Например, sitemap может содержать новый URL, но старый адрес приводить на другую страницу. Или переход может быть правильным, а canonical — указывать на прежний домен. Если смотреть только на один источник адреса, такое расхождение легко пропустить.
Удобная форма записи:
| Старый URL | Ответ и конечный URL | Canonical целевой страницы | URL в sitemap | Результат |
|---|---|---|---|---|
| исходный адрес | заполнить после проверки | значение из HTML | запись из карты | совпадает или требует разбора |
Сравнивай полный адрес, а не только имя домена. Важны соответствующая страница и выбранная версия URL. Если значения различаются, отметь конкретные поля: так будет понятно, что именно надо проверить повторно. Не меняй сразу несколько настроек без подтверждения причины — иначе при повторной сверке будет трудно установить, какое расхождение исправлено.
Эта сверка фиксирует проверяемые значения: что содержится в sitemap, куда ведёт старый URL и что указано в canonical. Записывай эти наблюдения отдельно от выводов о последующем поведении поисковой системы.
После правки повтори ту же постраничную сверку. Срок повторной проверки в переданных материалах не задан, поэтому не назначай универсальный интервал. Практический критерий простой: повторная строка должна показывать фактические значения после изменения, а не планируемый результат.
Разберите условный пример и перепроверьте исправление
Представь условную ситуацию: старый адрес https://old.example/catalog/x перенаправляет на https://new.example/catalog/x, но canonical на новой странице всё ещё указывает на старый адрес. Это учебный пример, не наблюдение за реальным сайтом. Здесь уже виден конкретный конфликт: фактический конечный URL находится на новом домене, а canonical ссылается на прежний.
Что делать дальше? Сначала подтверди, что https://new.example/catalog/x действительно является предпочтительной страницей для этой записи карты. Сверь адрес с постраничной картой и значением в sitemap. Если именно этот новый URL выбран как целевой и ошибка canonical подтверждена, исправь значение на странице или в настройке, которая формирует её HTML.
В переданных материалах не описаны конкретная панель, поле или последовательность нажатий. Поэтому проверяй не предполагаемое место изменения, а итоговое значение canonical в HTML страницы после правки.
Затем повтори всю тройную сверку: старый адрес должен фактически приводить к выбранной странице, canonical — указывать на предпочтительный адрес, sitemap — содержать соответствующий канонический URL. Если хотя бы одно значение осталось старым или ведёт на другую версию, отметь расхождение и проверь именно его. Не считай изменение настройки подтверждённым результатом, пока не посмотрел фактический адрес после исправления.
Для своей проверки возьми одну строку карты и заполни четыре поля: старый URL, конечный URL, canonical и запись sitemap. Сначала зафиксируй фактические значения, затем исправляй только подтверждённое несоответствие. Повторная строка покажет, согласованы ли адреса этой страницы после изменения.