Исправление канонического URL, указывающего на staging

Как выглядит симптом

Каждая страница на живом сайте отдает канонический адрес, называющий другой хост:

curl -s https://example.com/pricing | grep -i 'rel="canonical"'
<link rel="canonical" href="https://staging.example.com/pricing">

Search Console показывает это как "Дубликат, Google выбрал другой канонический URL, чем пользователь", либо как страницы, выпадающие из-за пользовательского канонического адреса на хосте, который вы никогда не подтверждали. Поскольку staging-хост обычно недоступен, защищен паролем или помечен noindex, объединению просто некуда деться, и живые страницы одна за другой перестают ранжироваться при каждом повторном обходе. Ничего не отдает 500, и ни одна проверка аптайма этого не замечает, именно поэтому это дорого обходится.

Откуда берется неверный базовый URL

• База данных, восстановленная из staging. В WordPress строки опций siteurl и home приносят имя хоста staging в продакшен, и каждый сгенерированный URL следует за ними.
• Переменная окружения в развернутой сборке. URL сайта, вшитый на этапе сборки, так что скомпилированный результат несет значение staging независимо от того, что говорит окружение выполнения.
• Хост по умолчанию фреймворка, настроенный отдельно для каждого окружения, когда конфигурацию продакшена так и не обновили после staging.
• Жестко прописанный абсолютный URL в общем макете или настройке SEO-плагина, записанный во время миграции и с тех пор не пересмотренный.
• Закэшированная страница, собранная на неверном хосте. CDN или кэш полной страницы, заполненный сборкой staging, еще долго после исправления конфигурации отдает устаревший HTML со staging-каноническим адресом.

Исправьте значение, затем устраните класс бага

1. Исправьте сохраненный базовый URL для продакшена, в том из перечисленных выше мест, которое применимо. В WordPress это две строки опций плюс любые абсолютные URL, записанные в содержимое постов копией staging.
2. Пересоберите и передеплойте, если значение скомпилировано внутрь. Изменение переменной окружения без пересборки оставляет старое значение в уже собранном бандле.
3. Очистите каждый кэш на пути следования: и приложения, и CDN, и границы сети. Исправленный источник за кэшем, полным HTML со staging, выглядит неисправленным столько, сколько живет этот кэш.
4. Предпочитайте выводить канонический адрес из хоста запроса, а не читать его из хранимой константы. Канонический адрес, построенный из хоста, отдавшего запрос, не может быть неверным в том окружении, где он был отдан, что убирает весь класс сбоя, а не только этот конкретный случай.
5. Держите staging вне индекса другими средствами. Защищать его должна HTTP-аутентификация или список разрешенных IP на хосте staging, а не канонический адрес и не noindex, который может путешествовать вместе с файлом конфигурации.

Проверьте исправление на продакшене

Читайте ответ, а не шаблон, потому что плагины, edge-воркеры и кэши все могут вставлять канонические адреса, которых нет в вашем репозитории:

curl -s https://example.com/pricing | grep -i 'rel="canonical"'
curl -sI https://example.com/pricing | grep -i '^link:'

Затем проверьте больше одной страницы. Канонический адрес генерируется шаблоном, поэтому верный результат на главной странице ничего не доказывает про страницы товаров, постраничные списки или что угодно, отрисовываемое другим макетом. В Search Console инструмент проверки URL показывает пользовательский канонический адрес рядом с тем, что выбрал Google, и их совпадение после повторного обхода - и есть то подтверждение, которое имеет значение. Этот повторный обход занимает дни, поэтому исправленный канонический адрес не вернет трафик в тот же день.

Не допустите, чтобы это повторилось

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

Проверяйте каждый шаблон, а не одну страницу

Начните с одной затронутой URL в бесплатной проверке канонического адреса: она разрешает канонический адрес и помечает тот, что указывает на другой хост, а именно так и выглядит канонический адрес staging. Затем посмотрите, проблема ли это одной страницы или целого макета, взглянув на них все сразу. Бесплатный инструмент обхода сайта проходит сайт и сообщает статус канонического адреса по каждому URL, вместе с флагами noindex и дублирующимся содержимым, которые обычно сопровождают неудачный деплой. Чтобы поймать следующий случай в день его публикации, включите опцию Indexability на HTTP-мониторе для ключевых страниц: она считывает канонический адрес при каждой проверке и отправляет уведомление, когда он меняется. SEO-мониторинг рассказывает, как это работает.