Виправлення канонічного посилання, що вказує на staging

Як виглядає симптом

Кожна сторінка на живому сайті віддає канонічне посилання, що називає інший хост:

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

Search Console показує це як "Дубльована сторінка, Google обрав канонічну версію, відмінну від зазначеної користувачем", або як сторінки, що випадають, із заявленим користувачем канонічним посиланням на хост, який ви ніколи не верифікували. Оскільки 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 і edge однаково. Виправлений origin за кешем, повним staging-HTML, виглядатиме невиправленим, поки живе цей кеш.
4. Віддавайте перевагу побудові канонічного посилання з хоста запиту, а не читанню збереженої константи. Канонічне посилання, побудоване з хоста, що обслуговував запит, не може бути неправильним у тому середовищі, де його обслужили, що усуває весь клас збою, а не лише цей конкретний випадок.
5. Тримайте staging поза індексом іншими засобами. HTTP-автентифікація чи allowlist за 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 Inspection показує заявлене користувачем канонічне посилання поруч із тим, яке обрав Google, і збіг цих двох після повторного обходу - те підтвердження, що має значення. Цей повторний обхід триває дні, тож виправлене канонічне посилання не поверне трафік того самого дня.

Не дайте цьому повторитися

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

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

Почніть з однієї постраждалої URL-адреси в безкоштовному перевіряльнику канонічних посилань: він розв'язує канонічне посилання й позначає те, що вказує на інший хост, а саме так і виглядає staging-канонічне посилання. Тоді з'ясуйте, чи проблема на одній сторінці, чи в одному макеті, поглянувши на всі одразу. Безкоштовний інструмент обходу сайту проходить сайтом і звітує про статус канонічного посилання для кожної URL-адреси, поряд із прапорцями noindex і дубльованими тілами, що зазвичай супроводжують невдалий деплой. Щоб упіймати наступний випадок того самого дня, як він з'явиться, увімкніть опцію Indexability на HTTP-моніторі для ваших ключових сторінок: він читає канонічне посилання при кожній перевірці й надсилає сповіщення, коли воно змінюється. Про те, як це працює, читайте в SEO-моніторингу.