После релиза все страницы отвечают 200, меню работает, sitemap обновлён. Через несколько дней поисковик выбирает старый URL или staging-домен. Причина часто лежит в одной строке внутри <head>: шаблон вывел неверный rel="canonical".
Не начинайте с повторной отправки sitemap. Сначала проверьте то, что реально получает робот в исходном HTML. DOM в DevTools может уже быть изменён JavaScript и скрывать ошибку серверного шаблона.
Проверка 1. Скачайте исходный HTML
На Windows откройте PowerShell. Команды сохранят заголовки и тело ответа в отдельные файлы.
$url = 'https://example.ru/catalog/item'
curl.exe -sS -D headers.txt -o page.html $url
Select-String -Path page.html -Pattern 'rel=["'']canonical["'']'PASS: найден ровно один тег, href абсолютный, использует production-домен и HTTPS. FAIL: тега нет, тегов два, указан staging, старый домен или URL с техническими параметрами.
Проверка 2. Куда приходит canonical-цель
curl.exe -sS -L -o NUL -w "HTTP=%{http_code} FINAL=%{url_effective}
" "https://example.ru/catalog/item"Подставьте значение href из canonical. Конечный URL должен отвечать 200. Если canonical ведёт через цепочку редиректов, на 404 или на страницу с noindex, сигнал конфликтует с реальным состоянием сайта.
| Проверка | PASS | FAIL |
|---|---|---|
| Количество canonical | Один | Ноль или несколько |
| Формат href | Абсолютный HTTPS URL | Staging, HTTP, технический параметр |
| Целевой ответ | 200 без смены смысла URL | 404, 5xx, длинная цепочка |
| Индексируемость цели | Нет noindex | Цель закрыта от индексации |
Проверка 3. Сигналы не должны спорить
Google использует несколько сигналов: redirects и rel=canonical сильнее, sitemap слабее. Если canonical указывает на URL A, sitemap содержит B, а внутренние ссылки ведут на C, поисковик будет разбираться сам. Результат может отличаться от ожиданий команды.
- Найдите текущую страницу в sitemap.xml.
- Убедитесь, что там стоит canonical URL без tracking-параметров.
- Проверьте ссылки из меню, хлебных крошек и связанных материалов.
- Проверьте HTTP→HTTPS и www→без www: все варианты должны приходить к одной выбранной версии.
- Повторите curl после очистки CDN-кэша, если релиз проходил через CDN.
Практический сценарий: staging попал в production
Сайт собирался с переменной SITE_URL=https://stage.example.ru. После переключения домена контент открывался на production, но metadata осталась из build-time environment. Браузер не показывал проблему на странице, потому что canonical не виден пользователю.
Исправление здесь не в ручной замене одной страницы. Нужно поправить источник SITE_URL, пересобрать release и проверить несколько шаблонов: главную, листинг, карточку, статью и страницу с параметрами.
PASS и FAIL для релиза
- PASS: исходный HTML содержит один абсолютный canonical на текущую production-версию.
- PASS: canonical-цель отвечает 200, разрешена к индексации и присутствует в sitemap.
- PASS: внутренние ссылки ведут на ту же версию URL.
- FAIL: браузерный DOM правильный, а curl всё ещё показывает staging.
- FAIL: canonical и редирект указывают на разные страницы.
Типичные ошибки
Проверять одну страницу. Metadata часто формируется по-разному для статических и динамических маршрутов.
Ставить noindex на дубль вместо canonical. Это другой сигнал и не помогает консолидировать версии так, как ожидает команда.
Оставлять старый URL во внутренних ссылках. Даже правильный canonical получает противоречивый сигнал от самого сайта.
Отправлять URL на переобход до исправления. Поисковик быстрее увидит ту же ошибку, а не её решение.
Проверьте шаблоны и URL с параметрами
Одна правильная карточка не доказывает исправность сайта. Возьмите по URL из каждого шаблона: главная, раздел, товар или услуга, статья, страница пагинации. Для каждого повторите получение исходного HTML и запишите canonical в таблицу приёмки.
Затем проверьте URL с безопасным параметром аналитики. Страница может открываться как ?utm_source=test, но canonical должен вести на чистую версию без tracking-параметра. Не удаляйте рабочие параметры редиректом вслепую: сначала убедитесь, что они не меняют содержимое.
Короткий релизный чек-лист
- Production host берётся из проверенной переменной окружения.
- В HTML каждого шаблона ровно один canonical.
- Canonical не меняется клиентским JavaScript.
- Целевой URL отвечает 200 и не содержит noindex.
- Sitemap и внутренние ссылки используют ту же версию.
Если сайт доступен с www и без www, через HTTP и HTTPS, отдельно проверьте все четыре входа. Они должны завершаться на выбранном host. Canonical не должен компенсировать сломанную цепочку редиректов.
После нового build снимите CDN-кэш только для проверяемых маршрутов, если инфраструктура это поддерживает. Массовая очистка иногда создаёт ненужную нагрузку и не объясняет, какой слой отдавал старое значение.
Что делать, если не помогло
Сравните HTML от curl с пунктом View Source и вкладкой Elements. Если canonical меняется только в DOM, ищите клиентский скрипт. Если HTML отличается между запросами, проверьте CDN, reverse proxy и A/B-тест. После исправления используйте URL Inspection, чтобы увидеть заявленный и выбранный Google canonical. При редизайне пригодится чек-лист сохранения SEO и техническая приёмка сайта. Мы можем проверить и доработать сайт до повторной индексации.
