Corriger une URL canonique qui pointe vers le staging

À quoi ressemble le symptôme

Chaque page du site en direct sert un canonique nommant un hôte différent :

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

Search Console l'affiche comme « Doublon, Google a choisi un canonique différent de celui de l'utilisateur », ou comme des pages qui sortent de l'index avec un canonique déclaré par l'utilisateur sur un hôte que vous n'avez jamais vérifié. Comme l'hôte de staging est normalement injoignable, protégé par mot de passe ou en noindex, il n'existe aucune destination sur laquelle la consolidation puisse atterrir, donc les pages en direct cessent simplement d'être classées, une recrawl à la fois. Rien ne renvoie 500 et aucune vérification de disponibilité ne le remarque, ce qui explique pourquoi c'est coûteux.

D'où vient la mauvaise URL de base

• Une base de données restaurée depuis le staging. Dans WordPress, les lignes d'option siteurl et home transportent le nom d'hôte du staging vers la production, et chaque URL générée les suit.
• Une variable d'environnement dans le build déployé. Une URL de site figée au moment du build, donc la sortie compilée porte la valeur du staging quoi que dise l'environnement d'exécution.
• Un hôte par défaut du framework configuré par environnement, où la config de production n'a jamais été mise à jour après celle du staging.
• Une URL absolue codée en dur dans un gabarit partagé ou un paramètre de plugin SEO, écrite pendant une migration et jamais revisitée.
• Une page mise en cache construite sur le mauvais hôte. Un CDN ou un cache de page complète peuplé par un build de staging sert du HTML périmé avec le canonique du staging bien après que la config a été corrigée.

Corrigez la valeur, puis éliminez la classe de bug

1. Corrigez l'URL de base stockée pour la production, dans celui des endroits ci-dessus qui s'applique. Dans WordPress, ce sont les deux lignes d'option plus toute URL absolue écrite dans le contenu des articles par la copie de staging.
2. Reconstruisez et redéployez si la valeur est compilée en dur. Changer une variable d'environnement sans reconstruction laisse l'ancienne valeur dans le bundle livré.
3. Purgez chaque cache sur le chemin, application, CDN et bordure confondus. Une origine corrigée derrière un cache plein de HTML de staging paraît non corrigée aussi longtemps que le cache vit.
4. Préférez dériver le canonique de l'hôte de la requête plutôt que de lire une constante stockée. Un canonique construit à partir de l'hôte qui a servi la requête ne peut pas être faux dans l'environnement où il a été servi, ce qui élimine toute la classe de panne plutôt que cette seule occurrence.
5. Gardez le staging hors de l'index par d'autres moyens. Une authentification HTTP ou une liste d'autorisation d'IP sur l'hôte de staging est ce qui devrait le protéger, pas un canonique, et pas un noindex qui peut voyager avec un fichier de config.

Vérifiez la correction en production

Lisez la réponse, pas le gabarit, car les plugins, les workers de bordure et les caches injectent tous des canoniques qui n'apparaissent pas dans votre dépôt :

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

Puis vérifiez plus d'une page. Le canonique est généré par un gabarit, donc bien faire la page d'accueil ne prouve rien sur les pages produit, les listes paginées ou tout ce qui est rendu par un gabarit différent. Dans Search Console, l'Inspection d'URL affiche le canonique déclaré par l'utilisateur à côté de celui que Google a sélectionné, et le fait que les deux concordent après une recrawl est la confirmation qui compte. Cette recrawl prend des jours, donc un canonique corrigé ne restaure pas le trafic le même après-midi.

Empêchez que ça se reproduise

Deux garde-fous ne coûtent presque rien. Le premier est une assertion au moment du déploiement : après une release, récupérez une poignée d'URL de production et faites échouer le déploiement si un canonique nomme un hôte autre que celui de production. Le second est de continuer à surveiller ensuite, car la panne a tout autant de chances d'arriver avec une restauration de base de données ou un paramètre de plugin qu'avec un déploiement de code. Les vérifications HTTP de HostTracker peuvent faire des assertions sur le corps et les en-têtes de la réponse, donc une vérification programmée peut être configurée pour échouer quand la balise canonique d'une page n'est pas celle attendue, et cet échec alerte comme n'importe quel autre.

Vérifiez chaque gabarit, pas une seule page

Commencez par une URL affectée dans le vérificateur de canonique gratuit : il résout le canonique et signale celui qui pointe vers un autre hôte, ce qui est exactement l'apparence d'un canonique de staging. Voyez ensuite si le problème touche une page ou tout un gabarit en les regardant toutes en même temps. L'outil de crawl de site gratuit parcourt le site et rapporte un statut de canonique par URL, aux côtés des indicateurs noindex et des corps dupliqués qui accompagnent en général un mauvais déploiement. Pour détecter le prochain le jour même de sa mise en ligne, activez l'option Indexability sur un moniteur HTTP pour vos pages clés : elle lit le canonique à chaque vérification et envoie une notification quand il change. Le monitoring SEO couvre comment cela fonctionne.