Début 2023, un client du secteur du voyage m'a contacté avec ce qui ressemblait à une configuration idéale. Il avait 14 000 pages de localisation, chaque ville, chaque arrondissement, chaque district postal du Royaume-Uni, tous générés automatiquement à partir d'une base de données d'hôtels et de restaurants. Template propre. Maillage interne décent. Et ça classait. Pendant environ quatre mois.
Ensuite, la mise à jour centrale de mars 2024 a frappé. Ils ont perdu 71% de leur trafic organique en six semaines. J'ai passé trois semaines à faire l'analyse. Le contenu n'était pas exactement faux. Mais c'était creux. Chaque page disait les mêmes trois choses dans un ordre légèrement mélangé, et Google avait clairement décidé que ce n'était pas la peine de le servir à quelqu'un. Nous avons reconstruit le pipeline avec des portes de qualité appropriées et nous avons récupéré 60% du pic en cinq mois. Pas parfait. Mais une leçon qui m'a marqué.March 2024 core update hit. They lost 71% of their organic traffic in six weeks. I spent three weeks doing the forensics. The content wasn't wrong exactly. But it was hollow. Every page said the same three things in slightly shuffled order, and Google had clearly decided it wasn't worth serving to anyone. We rebuilt the pipeline with proper quality gates and recovered to 60% of peak within five months. Not perfect. But a lesson that's stayed with me.
Le SEO programmatique est toujours l'un des outils les plus puissants de la boîte à outils d'une agence. Mais la marge de manœuvre pour le contenu IA généré est pratiquement nulle.
Ce que « Porte de qualité » signifie réellement dans un pipeline de pSEO
Les gens utilisent ce terme de façon vague, alors laissez-moi être précis sur la façon dont je l'utilise chez Seahawk.
Un contrôle de qualité est une règle ou un test à point de contrôle qu'une page doit passer avant d'être publiée, ou avant de rester publiée. Ce n'est pas une vérification au feeling. C'est un seuil spécifique et mesurable qui laisse passer une page ou la renvoie pour révision (ou la supprime complètement).checkpointed rule or test that a page must pass before it gets published, or before it stays published. It's not a vibe check. It's a specific, measurable threshold that either lets a page through or sends it back for revision (or kills it entirely).
Pensez-y comme à de l'intégration continue pour le contenu. Les développeurs ne poussent pas du code qui échoue les tests unitaires. Vous ne devriez pas publier de pages qui échouent les tests de contenu. L'analogie n'est pas parfaite, mais elle est assez proche pour être utile.
Un pipeline sans quality gates est juste une machine à spam de contenu. Et en 2024, le classifier de Google est assez bon pour détecter ça à grande échelle.
Les Trois Niveaux Où les Gates Doivent Se Trouver
Je structure les gates à trois moments :
- Pré-génération, avant que du contenu soit rédigé. Contrôles de qualité des données. Cet enregistrement dispose-t-il de suffisamment d'attributs uniques pour justifier une page distincte ?, before any content is written. Data quality checks. Does this entity have enough unique attributes to support a distinct page?
- Post-génération, après que l'IA ou le template a produit le contenu. Notation automatisée pour la longueur, l'unicité, la couverture des entités., after the AI or template has produced content. Automated scoring for length, uniqueness, entity coverage.
- Suivi post-publication, continu. Les pages qui connaissent une baisse d'impressions ou de taux de clic sont signalées pour examen humain., ongoing. Pages that drop in impressions or click-through rate get flagged for human review.
La plupart des équipes ne construisent que la couche du milieu. C'est pourquoi elles se font brûler.
Le Problème de Suffisance des Données (La Plupart des Gens Passent Cela)
Voilà la chose : les pires problèmes de contenu programmatique commencent avant qu'un mot soit écrit. Ils commencent dans le tableur.
Si vos données sources ont 12 attributs par entité et que 9 d'entre eux sont identiques dans 80% de vos enregistrements, vous allez produire des pages quasi-dupliquées peu importe la sophistication de vos prompts. J'ai appris ça sur un annuaire d'avocats que nous avons construit chez Seahawk en 2021. Nous avions 6 000 fiches de cabinets juridiques. Environ 4 200 d'entre elles n'avaient rien de distinctif au-delà d'un nom, d'un code postal et d'un domaine de pratique. Nous avons publié les 6 000. Google en a indexé environ 1 800.
Contrôle de pré-génération : notation de la richesse des données. Aujourd'hui, j'exécute chaque ensemble de données via un simple script Python avant de toucher à un template. Il compte le nombre de champs non nuls et non génériques par enregistrement et signale tout ce qui est en dessous d'un seuil ; j'utilise généralement 7 sur 12 comme minimum. Les enregistrements qui n'atteignent pas ce seuil vont dans une catégorie « stub » qui reçoit une page fine avec noindex, ou pas de page du tout. I now run every dataset through a simple Python script before we touch a template. It counts the number of non-null, non-generic fields per record and flags anything below a threshold, I typically use 7 out of 12 as a minimum. Records that don't clear it go into a "stub" category that gets a thin page with noindex, or no page at all.
Ce n'est pas glamour. Mais c'est le seul changement qui a eu le plus grand impact sur l'efficacité du crawl dans tous nos projets.
Notation d'unicité Après la génération
Donc vos données ont franchi la première étape. Le contenu a été généré. Et maintenant ?
Ne publiez pas tant que vous ne l'avez pas noté pour son unicité, non pas par rapport au web, mais par rapport à votre propre corpus de pages. Le contenu interne quasi-dupliqué est le problème le plus courant, et c'est celui sur lequel vous avez le plus d'emprise immédiatement.
J'utilise une combinaison de deux outils pour ça :
- [L'API batch de Copyscape](https://www.copyscape.com/api.php) pour signaler les pages qui sont trop similaires aux URLs déjà indexées for flagging pages that are too similar to existing indexed URLs
- Un script de similarité cosinus personnalisé (utilisant sentence-transformers en Python) qui note chaque nouvelle page par rapport aux 50 pages les plus structurellement similaires de la même famille de templates
Mon seuil est 0,82 de similarité cosinus. Tout ce qui dépasse ça va en révision manuelle. Au-dessus de 0,91, c'est supprimé ou lourdement retravaillé.
Oui, ça ajoute de la friction au pipeline. Tant mieux. La friction, c'est le but.
Ce que "Unique" Doit Vraiment Signifier
Véritablement unique ne signifie pas juste des phrases mélangées. Ça signifie que la page répond à une question que seule cette entité peut poser. Pour une page d'atterrissage de ville, c'est des données hyper-locales, des listes d'événements réels, des statistiques locales réelles, une citation spécifique d'une source locale. Pour une page de comparaison de produits, ce sont des points de données qui différencient ces deux produits spécifiques, pas une intro boilerplate avec des noms échangés.this entity can answer. For a city landing page, that's hyper-local data, real event listings, actual local statistics, a specific quote from a local source. For a product comparison page, it's data points that differentiate these two specific products, not a boilerplate intro with swapped nouns.
C'est ce que Google dit dans ses propres directives sur le contenu utile depuis toujours. Le classificateur s'est juste montré agressif dans l'application. has always said this. The classifier just got aggressive about enforcing it.
Entity Coverage : La Barrière dont Personne ne Parle
Ça m'a pris plus de temps à découvrir que je ne le voudrais, et ça m'énerve.
Chaque page dans une construction programmatique est nominalement "à propos" de quelque chose — un lieu, un produit, une personne, un service. L'entité et ses attributs doivent être représentés de façon cohérente dans le contenu à travers des mentions nommées, des associations sémantiques et des données structurées. S'ils ne le sont pas, la page paraît mince même si elle fait 800 mots.
Je fais maintenant une analyse NLP légère sur chaque page générée en utilisant spaCy pour vérifier que :spaCy to check that:
- L'entité principale est nommée dans les 100 premiers mots
- Au moins 4 entités ou attributs sémantiquement liés apparaissent dans le corps du texte
- La page contient au moins un fait unique à l'entité (extrait des données sources, non généré par le modèle)
Cette dernière vérification est manuelle pour l'instant. Je veux l'automatiser mais je n'ai pas encore développé de méthode fiable pour valider les références croisées à grande échelle sans trop de faux positifs. Si tu as résolu ce problème, j'aimerais vraiment le savoir.
Le piège des pages minces : Quand utiliser noindex plutôt que de supprimer
Admettons qu'une page soit générée mais reste minimaliste. Peut-être que les données étaient insuffisantes, l'entité est obscure, et le résultat est techniquement unique mais pas particulièrement utile.
Que fais-tu ?
Voici mon arbre décisionnel, simplifié, mais c'est à peu près comme ça que j'y réfléchis :
- Si la page a zéro impression de recherche après 90 jours dans GSC : supprimer et rediriger en 301 vers la page parente la plus pertinente.delete and 301 to the nearest relevant parent.
- Si la page a des impressions mais un CTR inférieur à 0,5 % et aucun lien retour : noindex et consolider dans une page parente ou une page de catégorie.noindex and consolidate into a parent or category page.
- Si la page a des impressions, un CTR raisonnable (1 %+), mais une position moyenne basse (40+) : conserver, mais prioriser pour l'enrichissement du contenu.keep, but prioritise for content enrichment.
- Si la page performe : laissez-la tranquille et arrêtez de vous remettre en question.leave it alone and stop second-guessing yourself.
Je ne peux pas vous dire combien de fois j'ai vu des agences noindexer des pages qui convertissaient tranquillement. Ne réparez pas ce qui n'est pas cassé.
Les données structurées comme signal de qualité (pas seulement pour les résultats enrichis)
La plupart des gens ajoutent du schema aux pages pSEO pour les résultats enrichis. C'est compréhensible. Mais j'ai commencé à traiter la complétude du schema comme une barrière de contrôle qualité aussi.
Si le schéma d'une page compte plus de 30 % de valeurs nulles ou fictives, cela me dit que les données sous-jacentes sont trop maigres pour produire une page utile. Nous avons donc intégré un validateur de schéma dans notre pipeline — il vérifie les propriétés obligatoires et recommandées par rapport à la spécification Schema.org pour le type que nous utilisons. Les pages qui échouent ce contrôle retournent dans la queue d'enrichissement.Schema.org spec for whatever type we're using. Pages that fail this check go back into the enrichment queue.
Google utilise-t-il l'exhaustivité du schéma comme signal de classement direct ? Presque certainement pas de façon simple. Mais les pages avec un schéma complet et exact tendent à être des pages avec des données complètes et exactes, et ces pages tendent à se classer. La corrélation est assez forte pour que je traite la qualité du schéma comme un diagnostic utile, même si ce n'est pas le mécanisme.those pages tend to rank. The correlation is strong enough that I treat schema quality as a useful diagnostic even if it's not the mechanism.
Suivi après publication : la barrière qui continue de fonctionner
Une barrière de qualité n'est pas une affaire ponctuelle. Les pages se dégradent. Les données deviennent obsolètes. Une page qui allait bien en janvier pourrait être mince en octobre parce que le monde a bougé et le contenu non.
Je fais un crawl mensuel avec Screaming Frog sur chaque grosse propriété pSEO qu'on gère, en signalant :Screaming Frog on every large pSEO property we manage, flagging:
- Les pages sous 350 mots (après suppression du boilerplate)
- Pages dont les balises de titre correspondent à plus de 3 autres pages du site
- Pages sans liens internes pointant vers elles (risque d'orphelinat)
Je les recoupé avec les données de GSC exportées via l'API, en cherchant spécifiquement les pages qui ont perdu plus de 40 % de leurs impressions au cours des 60 derniers jours. Cette intersection (signalée par Screaming Frog et en déclin dans GSC) est la queue de révision à priorité élevée.and declining in GSC) is the high-priority review queue.
Honnêtement, cette étape de surveillance est celle où la plupart des agences font des raccourcis parce qu'elle n'est pas facturée de manière évidente. Mais c'est ce qui sépare une construction pSEO durable d'une qui s'effondre après la prochaine mise à jour de base.
FAQ
L'utilisation de l'IA pour générer du contenu déclenche-t-elle automatiquement une pénalité Google ?
Non. Google a déclaré explicitement que le contenu généré par l'IA n'est pas contre ses directives — c'est le contenu peu utile qui pose problème, indépendamment de la façon dont il a été produit. Le signal, c'est la qualité, pas l'origine. Une page rédigée manuellement qui est mince et dupliquée sera traitée de la même façon. Ce qui compte, c'est si la page sert vraiment mieux la requête de l'utilisateur que les alternatives. Si ce n'est pas le cas, la méthode de production est sans importance.unhelpful content that's the problem, regardless of how it was produced. The signal is quality, not origin. A manually written page that's thin and duplicative will get treated the same way. What matters is whether the page genuinely serves the user's query better than the alternatives. If it doesn't, the method of production is irrelevant.
Combien de pages constituent « trop » pour une construction programmée avant que Google ne devienne soupçonneux ?
Il n'y a pas de chiffre fixe, et tout chiffre spécifique que vous avez vu en ligne est inventé. Ce qui compte, c'est le ratio entre les pages indexées et les pages classées. Si vous avez 20 000 pages et que 400 reçoivent des impressions, c'est un problème de budget de crawl et de qualité. Google commencera à ignorer le reste. Je préfère publier 3 000 pages solides plutôt que 20 000 médiocres. Le taux de couverture d'index est la métrique à surveiller, pas le nombre absolu de pages.
Puis-je me rétablir après avoir été frappé par la pénalité des contenus IA ?
Oui, mais cela prend du temps et ce n'est pas linéaire. Le client du secteur du voyage dont j'ai parlé au début s'est rétabli, mais cela a pris un travail régulier sur cinq mois : supprimer les pires pages, consolider les médiocres, enrichir les meilleures. L'action la plus impactante a été de réduire l'index de 14 000 pages à environ 4 200. Contre-intuitif, mais c'est ce que les données ont montré.
Quel est le moyen le plus rapide d'identifier quelles pages dans une large construction sont du « remplissage » ?
Extrayez vos données de performance GSC complètes des 16 dernières semaines. Filtrez les pages avec plus de 0 impressions mais moins de 0,8 % CTR et une position moyenne pire que 35. Cet ensemble est votre problème. Recoupez avec le nombre de mots et le nombre de liens internes. Le chevauchement entre pages avec faible CTR, peu de mots et pages orphelines est presque toujours la partie la plus faible de n'importe quelle construction programmatique.
---
Construire à grande échelle ne vous donne pas la permission de construire mal. Les garde-fous que j'ai décrits ajoutent environ deux à trois jours de temps de configuration à un nouveau projet pSEO. L'alternative, reconstruire après qu'une mise à jour core vous anéantisse, coûte beaucoup plus que cela. Je le sais parce que j'ai fait les deux.