Au début 2023, un client dans le secteur du voyage est venu me voir avec ce qui ressemblait à un rêve de configuration. Il avait 14 000 pages de localisation — chaque ville, chaque arrondissement, chaque zone de code postal au Royaume-Uni — tous auto-générés à partir d'une base de données d'hôtels et de restaurants. Template propre. Linking interne décent. Et ça s'est bien classé. 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.
Une quality gate est une règle ou un test contrôlé qu'une page doit réussir avant d'être publiée — ou avant de rester publiée. Ce n'est pas un jugement à l'instinct. C'est un seuil spécifique et mesurable qui laisse passer une page ou la renvoie en révision (ou la supprime entièrement).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 écrit. Vérifications de la qualité des données. Cette entité a-t-elle assez d'attributs uniques pour supporter 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 modèle ait produit le contenu. Scoring automatisé pour la longueur, l'unicité, la couverture d'entité. — after the AI or template has produced content. Automated scoring for length, uniqueness, entity coverage.
- Monitoring post-publication — en continu. Les pages qui chutent en impressions ou en taux de clics sont signalées pour révision humaine. — 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à le truc — les pires problèmes de contenu programmatique commencent avant qu'un seul mot ne soit écrit. Ils commencent dans la feuille de calcul.
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.
Filtre pré-génération : notation de richesse des données. Maintenant je fais passer chaque dataset par 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 ne passent pas cette étape vont dans une catégorie « stub » qui reçoit une page allégée avec noindex, ou aucune 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 avant de l'avoir 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 de contrôle 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 réarrangées. Ça signifie que la page répond à une question que seule cette entité peut répondre. Pour une page d'atterrissage locale, c'est des données hyper-locales — des listes d'événements réels, des statistiques locales actuelles, une citation précise 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 standardisée 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 d'une construction programmatique concerne nominalement quelque chose — un lieu, un produit, une personne, un service. L'entité et ses attributs devraient être représentés de façon cohérente dans le contenu par des mentions nommées, des associations sémantiques et des données structurées. Si ce n'est pas le cas, la page semble 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 de décision — simplifié, mais c'est à peu près comment 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 schema d'une page contient plus de 30 % de valeurs nulles ou placeholder, cela m'indique que les données sous-jacentes sont trop maigres pour produire une page utile. On a donc construit un validateur de schema dans notre pipeline — il vérifie les propriétés requises et recommandées par rapport à la spec Schema.org pour le type qu'on utilise. Les pages qui échouent ce test 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 la complétude du schema comme signal de classement direct ? Presque certainement pas d'une manière simple. Mais les pages avec un schema 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 schema 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 fais une correspondance croisée 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 baisse dans GSC) constitue la file d'attente d'examen prioritaire.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 explicitement déclaré que le contenu généré par l'IA n'est pas contraire à ses directives — c'est le contenu peu utile qui pose problème, indépendamment de sa source. Le signal, c'est la qualité, pas l'origine. Une page écrite manuellement qui est fine et dupliquée sera traitée de la même manière. Ce qui compte, c'est si la page répond réellement mieux à la requête de l'utilisateur que les alternatives. Si ce n'est pas le cas, la méthode de production n'a aucune 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 ça prend du temps et ce n'est pas linéaire. Le client dans le secteur du voyage que j'ai mentionné au début s'est rétabli — mais ça a pris du travail constant pendant cinq mois : supprimer les pires pages, consolider les pages de niveau intermédiaire, enrichir les meilleures. L'action unique la plus impactante a été de réduire l'index de 14 000 pages à environ 4 200. C'est 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 mal construire. Les garde-fous que j'ai décrits ajoutent peut-être deux à trois jours de temps de configuration à un nouveau projet pSEO. L'alternative — reconstruire après qu'une mise à jour centrale vous élimine — coûte beaucoup plus que ça. Je le sais parce que j'ai fait les deux.