Balises canonical détournées après un piratage

Ce que Google fait d'une canonical

La balise `rel=canonical` dit quelle URL est la version à indexer. Si elle pointe vers `https://autre-domaine.shop/votre-slug`, Google tend à fusionner chez eux. Vous gardez parfois une ligne dans l'index, parfois plus rien.

Ce n'est pas une redirection visiteurs. Vous voyez encore votre page. D'où le diagnostic tardif : « le site marche, Google non ». L'inspection d'URL montre la canonical servie à Googlebot.

Une action manuelle n'est pas obligatoire. Le dégât est silencieux. On le découvre quand les titres SERP changent ou que le trafic organique glisse. Trafic effondré.

Ouvrez trois pages (home, un article, un produit) en affichage source, déconnecté, et cherchez `rel="canonical"`. Deux balises dans le même HTML : Google improvise, souvent mal. Une seule vers un tiers : consolidation ailleurs. Aucune : ce n'est pas ce dossier, passez à noindex / robots / action manuelle. Cette lecture de trente secondes évite de « vider toutes les canonicals » — le geste qui crée de la duplication interne et un second incident SEO par-dessus le piratage.

Où la balise est écrite

Yoast, Rank Math, SEOPress : réglage global « domaine canonique » ou champ par contenu. Une option `wp_options` réécrite (`wpseo`, `rank-math-options`) suffit. L'admin affiche encore votre URL si le plugin lit un cache.

Le thème : `header.php`, `functions.php`, un `echo` dans `wp_head`. Un thème nulled le fait dès l'installation. Thème nulled.

Un mu-plugin ou un PHP dans `uploads` accroché à `wp_head`. `wp-config.php` rarement, sauf `define` bizarre repris par un must-use. Grepez `rel="canonical"` et `rel='canonical'` sur tout le compte.

• Options des plugins SEO (base).
• header.php / wp_head.
• mu-plugins et includes uploads.

Plugin SEO vs thème vs header PHP

Deux canonicals dans le même HTML : Google improvise. Après un hack, on trouve souvent le plugin correct et une seconde balise injectée. Il faut retirer l'injection, pas désinstaller Yoast « au cas où ».

Elementor et les builders ajoutent parfois une canonical dans le document JSON. Ouvrez une page type, cherchez le domaine tiers en brut.

WooCommerce : canonicals produit / catégorie via le plugin SEO. Un SKU dont la canonical pointe vers un dropshipping externe est un signal shopping en plus. Merchant.

Canonical vers HTTP ou un sous-domaine sale

Moins spectaculaire qu'un casino : `http://` alors que le site est en HTTPS, ou `www` vs nu inversé. Google consolide mal, le trafic se disperse. Vérifiez que ce n'est pas un vieux réglage — mais une modification datée le jour du hack n'est pas un vieux réglage.

Un sous-domaine `amp.`, `m.`, `cdn.` oublié, encore infecté, déclaré canonical : vous envoyez l'autorité vers la zone sale. Nettoyez ce host ou retirez la balise. Les addon domains du panel font la même chose.

Corriger sans casser les vraies règles

Les pagination, les facettes, les produits à variantes ont des canonicals légitimes. On ne « vide pas toutes les canonicals ». On remet l'URL HTTPS de la page, ou la règle métier d'avant l'incident (captures, staging, zip de thème).

Sauvegardez `wp_options` avant une passe SQL. Une sérialisation PHP cassée (longueur de chaîne) met le site KO. Si vous n'êtes pas à l'aise, arrêtez-vous. Supprimer un malware WP.

Purgez cache plugin, CDN, object cache. La canonical est dans le HTML : un cache « tout le site » la ressert sale.

Réindexation des templates

Demandez l'indexation de la home, d'un article, d'une catégorie, d'un produit — les types, pas les 8 000 URL. Google recrawlera les autres. Un retrait de préfixe n'est utile que si les URL elles-mêmes étaient du spam.

Les rich results peuvent disparaître le temps que le HTML redevienne cohérent (schema + canonical). Rich results perdues.

hreflang et Open Graph dans la même passe

Les `hreflang` vers un domaine tiers font le même travail de consolidation linguistique. Les `og:url` trompent Facebook/LinkedIn plus que Google, mais se cherchent au même grep.

Un pack « multilingual pirate » ajoute des x-default vers un shop asiatique. Relisez l'en-tête complet dans l'inspection, pas seulement la canonical.

Contrôle à J+7

Réinspectez trois URL. Canonical = vous. Si le domaine tiers revient, une backdoor réécrit l'option ou le header. Backdoor PHP.

Page cas WordPress. Constat : créer un espace.

À J+7, si la canonical tierce revient, quelqu'un (ou un cron, ou un mu-plugin) réécrit l'option ou le `wp_head`. Ce n'est plus du SEO, c'est une porte. Backdoor PHP. Page cas WordPress piraté. Pour corriger base + thème sans casser la sérialisation, créez un espace.

Grep, options sérialisées, et ce qu'il ne faut pas SQL-er

Grepez `rel="canonical"`, `rel='canonical'` et le domaine tiers sur tout le compte. Un hit dans un mu-plugin clôt. Un hit seulement dans `wp_options` (longueur de chaîne dans une sérialisation PHP) : sauvegardez la table, corrigez la longueur si vous éditez à la main, ou passez par l'UI du plugin SEO. Une sérialisation cassée = écran blanc.

WooCommerce : une canonical produit vers un dropshipping externe est aussi un signal Shopping. Merchant. Elementor : le domaine peut être dans le JSON, invisible dans header.php.

À J+7, trois inspections. Si le tiers revient, ce n'est plus une balise oubliée : une porte réécrit. Backdoor PHP.

Récap : ce qui suffit pour la semaine

Trois pages inspectées, une seule canonical HTTPS vers vous, pas de seconde balise, pas de hreflang vers un tiers. Cache et CDN purgés. Option SEO relue, mu-plugins listés. Si le domaine étranger revient à J+7, cessez de « corriger la balise » : cherchez qui l'écrit. WordPress piraté.

N'effacez pas toutes les canonicals « pour simplifier ». Pagination et variantes produit en ont besoin. Rank Math et Yoast ensemble : n'en gardez qu'un. Bing lit le même HTML. Créer un espace si la sérialisation vous bloque.

• Home, article, produit : inspection.
• Grep du domaine tiers.
• Purge cache.
• Contrôle J+7.