Checklist SEO Pré-Publication

L’assurance qualité (QA) pré-publication est le dernier portail de mise en ligne dans le processus SEO . C’est là que trois contrats se rencontrent : la conformité au type de publication, l’utilisation correcte des éléments et l’achèvement des travaux de recherche, de mise en évidence, de mise en œuvre et de relecture précédents. Une page qui échoue à un élément applicable quelconque retourne pour correction.

Portail : QA finale pré-publication. Durée : 60 à 90 minutes pour une page standard ; ajoutez du temps spécialisé pour les réglementations, la sécurité, les finances, le médical ou les affirmations techniquement conséquentes. Responsable : un rédacteur, responsable contenu ou responsable SEO qui n’a pas effectué la mise en œuvre finale et qui a l’autorité de bloquer la mise en ligne.

Une checklist molle n’est pas une checklist car « presque terminé » n’a pas de signification stable. Sous pression de délai, un wording optionnel devient une aide-mémoire et les contrôles difficiles disparaissent. Nommez l’autorité de mise en ligne avant le début de la QA. Le responsable QA peut valider ou échouer ; seul le responsable du contenu, responsable SEO ou équivalent nommé peut approuver une exception écrite ou déclarer un élément non applicable. Ils ne peuvent pas renoncer à une affirmation fausse, à un élément obligatoire manquant, à une ressource factice, à une canonique cassée ou à une indexabilité bloquée pour respecter une date.

Pourquoi ce portail existe et pourquoi il intervient ici

Ce portail consomme la spécification approuvée du type de publication, les contrats des éléments, l’enregistrement source, le texte final, le candidat implémenté et les approbations spécialisées. Il intervient après que ces entrées sont figées car la QA ne peut pas vérifier une cible mouvante, et avant la publication car un défaut peut être copié dès que l’URL est en ligne.

La QA préalable certifie un brouillon qui peut changer. La sauter laisse les auditeurs ultérieurs incapables de distinguer une dérive de page, une spécification modifiée et une page jamais vérifiée. La QA post-publication transforme des corrections peu coûteuses en défauts publics.

Entrées et sorties

La sortie est un contrat, pas un message de discussion. Le publiant doit pouvoir agir dessus sans reconstruire la relecture.

La checklist

Chaque élément ci-dessous inclut l’action, la raison, la méthode, l’outil et la condition observable de réussite. « Vérifié SEO » ou « semble bon » n’est jamais une preuve acceptable.

1. Conformité au type de publication

Confirmer le type de publication et le périmètre choisis. Quoi : faire correspondre le candidat à une entrée de la bibliothèque des types de publication et retirer le contenu appartenant à un type frère. Pourquoi : le type de page détermine l’intention, la structure, les preuves et le comportement de conversion. Comment : étiqueter chaque section avec la décision du lecteur qu’elle soutient et la comparer à l’objectif et aux exclusions du type. Outil : brief approuvé, carte thématique et pages des types de publication. Réussi quand : exactement un type principal est enregistré, l’ouverture, le corps et l’appel à l’action le servent, et aucune section n’existe uniquement pour le rôle d’un autre type.

Tracer la structure requise et les fourchettes de mots. Quoi : mapper chaque section requise au candidat rendu et compter ses mots par rapport à la fourchette spécifiée. Pourquoi : les sections manquantes créent des questions sans réponse, tandis qu’une longueur non maîtrisée cache les lacunes derrière le volume. Comment : utiliser une matrice de correspondance exigence-titre et des comptages automatisés, puis inspecter les cas limites manuellement. Outil : spécification du type de publication, source et page rendue. Réussi quand : aucune section requise n’est manquante et chaque section se situe dans son minimum et maximum déclarés.

2. Conformité des éléments

Vérifier les éléments, positions et paramètres. Quoi : comparer la carte des éléments avec la source et le rendu. Pourquoi : la position et les champs font partie de la fonction ; une réponse directe enterrée ne répond plus en premier, et des paramètres mal formés peuvent casser la sortie. Comment : inspecter de haut en bas et valider les champs autorisés, les valeurs, l’imbrication et la syntaxe. Outil : spécifications des éléments, validateur et navigateur. Réussi quand : chaque élément obligatoire est à sa position requise, chaque paramètre est valide et aucun doublon inexpliqué ne subsiste.

Appliquer la précédence des éléments typés. Quoi : appliquer les règles d’écriture des éléments partout où un passage a un objectif enregistré. Pourquoi : le texte libre peut sembler similaire mais ne peut pas porter l’identité du composant, les champs, le comportement d’accessibilité ou la sortie structurée. Comment : énoncer le travail de chaque bloc comme un verbe — définir, avertir, comparer, instruire, résumer — et vérifier s’il existe un élément correspondant. Outil : bibliothèque des éléments et inspecteur source. Réussi quand : aucun passage n’utilise de texte libre là où un élément typé est obligatoire.

3. Qualité du contenu

Tester la réponse en isolation. Quoi : lire le bloc de réponse directe sans son titre ni ses paragraphes environnants. Pourquoi : les systèmes de recherche et d’extraction IA peuvent n’extraire que ce passage. Comment : vérifier qu’il nomme le sujet, répond à la question, inclut les qualifications nécessaires et ne repose pas sur « ceci », « cela » ou « comme ci-dessus ». Outil : vue texte isolé et relecteur humain. Réussi quand : la réponse est autonome, précise et se situe dans sa fourchette spécifiée de 40 à 60 mots lorsque cet élément est requis.

Vérifier les affirmations, le langage et l’unicité. Quoi : tracer les affirmations matérielles jusqu’aux preuves, expliquer le jargon dès la première utilisation et comparer le candidat aux pages servant la même intention. Pourquoi : les affirmations non étayées nuisent à la confiance, tandis que les quasi-doublons se concurrencent et dérivent. Comment : signaler les noms, dates, chiffres, affirmations causales, comportements de produit et candidats à la similarité ; les étayer, qualifier, consolider ou supprimer. Outil : registre des preuves, sources primaires, recherche sur le site et rapport de similarité. Réussi quand : aucune affirmation matérielle n’est sans soutien, aucun terme spécialisé ne reste inexpliqué, et aucune page existante ne répond à la même intention et au même périmètre sans un plan de consolidation.

4. Frontmatter

Valider les champs d’identité et d’aperçu. Quoi : appliquer la spécification du frontmatter au titre, à la description, aux mots-clés, à entity et aux jointures de type de publication. Pourquoi : ces champs pilotent le routage, les aperçus, les schémas et les relations sans lire le corps. Comment : exécuter une validation de champ et de longueur, puis comparer le sens avec la page visible. Outil : linter de frontmatter et aperçu humain. Réussi quand : le titre est unique et précis, la description fait 150 à 160 caractères, les mots-clés contiennent 6 à 8 entrées pertinentes, et entity correspond au contrat du type de publication.

Vérifier les champs de gouvernance et FAQ. Quoi : vérifier les dates, l’auteur, le relecteur, la propriété et la structure FAQ visible par rapport au frontmatter. Pourquoi : les enregistrements anonymes empêchent la responsabilisation, tandis que la dérive FAQ fait diverger les réponses visibles et structurées. Comment : comparer les champs avec la trace de publication et le texte visible normalisé. Outil : analyseur source, traqueur et page rendue. Réussi quand : les dates et propriétaires requis sont valides, le relecteur humain est nommé là où requis, le nombre de FAQ atteint le minimum du type, chaque paire correspond, et aucune entrée cachée ou vide ne subsiste.

5. Données structurées

Exiger le schéma correct. Quoi : confirmer que le balisage schéma applicable existe pour la page et ses éléments visibles. Pourquoi : un balisage manquant ou générique rejette la signification lisible par machine que le modèle de contenu fournit déjà. Comment : comparer les types et propriétés émis avec les contrats du type de publication et des éléments. Outil : HTML rendu et validateur de schéma. Réussi quand : chaque type de schéma requis est présent une fois, les propriétés requises sont renseignées, et aucun type non applicable n’est émis.

Valider la parité, pas seulement la syntaxe. Quoi : comparer les noms, dates, auteur, entité, FAQ, étapes et affirmations du schéma avec le contenu visible. Pourquoi : une syntaxe valide peut toujours décrire des informations invisibles ou contradictoires. Comment : valider le JSON-LD, puis comparer les valeurs avec la page. Outil : test de données structurées et relecture humaine. Réussi quand : il n’y a aucune erreur et aucun fait dans le schéma qui contredit ou dépasse le contenu visible.

6. Liens internes

Lier vers le haut et vers l’extérieur. Quoi : fournir un chemin vers le pilier pertinent et des chemins contextuels vers les nœuds connexes. Pourquoi : la hiérarchie aide les lecteurs et les robots à comprendre où la page se situe, tandis que les liens latéraux poursuivent la tâche du lecteur. Comment : mapper chaque lien interne à une véritable question suivante plutôt que de remplir un quota. Outil : graphe de liens et page rendue. Réussi quand : la page a au moins un lien vers son pilier, au moins un lien latéral pertinent là où un nœud connexe existe, et au moins une page existante pointe vers elle avant ou au moment de la publication afin qu’elle ne soit pas orpheline.

Inspecter les destinations et les ancres. Quoi : ouvrir chaque destination et examiner son texte d’ancrage . Pourquoi : une URL plausible peut être manquante, redirigée ou sans rapport, et les étiquettes génériques cachent l’objectif de la destination. Comment : exécuter un vérificateur de liens internes, puis inspecter manuellement les ancres en contexte de phrase. Outil : robot d’exploration et navigateur. Réussi quand : aucun lien interne ne retourne d’erreur, chaque destination soutient l’affirmation environnante, et aucun « cliquez ici » isolé, URL brute ou ancre correspondante exacte trompeuse ne subsiste.

7. Médias

Vérifier les ressources, les alternatives et l’actualité. Quoi : confirmer que chaque image existe, a un texte alternatif pertinent ou une alternative vide justifiée, et reflète l’interface actuelle. Pourquoi : des médias cassés, vagues, factices ou obsolètes suppriment des informations et peuvent rendre les instructions inutilisables. Comment : désactiver les images, inspecter les chemins, reproduire les étapes produit et comparer les étiquettes, valeurs, recadrages et caviardages. Outil : vérificateur de ressources, audit d’accessibilité, produit en direct et navigateur. Réussi quand : aucune ressource n’est manquante ou factice, les alternatives sont précises, et chaque capture d’écran représente l’étape actuelle.

8. Mise en ligne technique

Vérifier le routage, l’indexabilité et le remplacement. Quoi : vérifier le slug, une URL canonique auto-référencée, le statut, le comportement robots, l’indexabilité et les redirections. Pourquoi : le contenu ne peut pas performer sur la mauvaise route, derrière noindex, ou après que d’anciennes URL sont laissées à l’abandon. Comment : inspecter l’en-tête rendu et la réponse, comparer le registre et suivre chaque route remplacée. Outil : vérificateur d’en-tête, carte de redirection, inspecteur source et inspection d’URL. Réussi quand : l’URL approuvée retourne 200 avec une seule canonique prévue et aucun blocage ; chaque URL remplacée effectue un seul saut permanent vers le remplacement valide le plus proche.

Tester la stabilité mobile. Quoi : inspecter la lecture à largeur réduite, l’interaction, le débordement et le Cumulative Layout Shift . Pourquoi : les composants qui fonctionnent sur desktop peuvent masquer des contrôles, tronquer des tableaux ou déplacer du contenu au fur et à mesure du chargement des médias. Comment : tester des largeurs mobiles représentatives et charger la page avec limitation de débit. Outil : mode appareil du navigateur et rapport de performance. Réussi quand : tout le contenu et les contrôles restent utilisables sans débordement horizontal de la page et le CLS mesuré est de 0,1 ou moins.

9. Préparation IA

Tester l’extraction et le HTML initial. Quoi : inspecter les réponses, définitions, faits clés, comparaisons et conclusions en tant que passages indépendants dans le HTML livré par le serveur. Pourquoi : les systèmes de récupération peuvent sélectionner un seul passage et peuvent ne pas exécuter le code côté client. Comment : récupérer le HTML initial, supprimer le contexte environnant et vérifier les noms d’entité, qualificatifs, unités et pronoms. Outil : récupération HTML, extracteur de passages, navigateur et audit AmICited. Réussi quand : chaque fait prioritaire est présent sans JavaScript et conserve seul son sujet, sa signification et ses limitations.

Exposer la structure procédurale. Quoi : vérifier que les paires FAQ et les étapes ordonnées sont encodées comme des champs reconnaissables et restent visibles. Pourquoi : les titres et les boîtes stylisées peuvent sembler corrects tandis que les machines reçoivent une prose non structurée. Comment : comparer la sortie des éléments, la structure accessible et le schéma avec la séquence visible. Outil : arbre d’accessibilité et validateur de données structurées. Réussi quand : chaque FAQ requise est lisible par machine comme une paire question-réponse et chaque procédure requise préserve les étapes ordonnées dans la sortie visible et structurée.

Outils dans AmICited

Utilisez le produit pour inspecter le candidat et établir les preuves de transfert ; il ne remplace pas le jugement humain.

1. Ouvrez l’audit de préparation des agents avec Accessibilité IA et préparation des agents pour inspecter l’accessibilité, l’atteignabilité par les robots, la couverture du sitemap et le contenu lisible par les agents.
2. Inspectez l’URL candidate avec Inspection d’URL pour vérifier l’état d’indexation, l’utilisabilité mobile et le verdict des résultats enrichis. Assignez une inspection en direct dans le transfert pour une nouvelle URL.
3. Ouvrez l’audit de fraîcheur avec Fraîcheur du contenu pour donner aux pages sensibles au temps un signal de maintenance et une date de prochaine relecture. L’historique commence lorsque le suivi commence ; pas d’historique ne signifie pas aucun changement.
4. Utilisez SEO MCP via la connexion de l’espace de travail pour des vérifications reproductibles en lecture seule d’URL, de fraîcheur, de Web Vitals et d’accessibilité. Stockez la sortie ou l’identifiant d’exécution.

Automatisation : scriptez les contrôles déterministes, préservez les décisions humaines

Un contrôle qui peut être scripté mais reste manuel sera ignoré sous pression. Automatisez les résultats stables et observables par machine ; exigez un humain pour l’objectif, la vérité et le contexte.

L’automatisation écrit les preuves, pas l’approbation. Un échec bloque le portail ; un script réussi ne valide pas les colonnes humaines.

Règles de décision

« Mauvais » doit être observable. Utilisez ces seuils sauf si le type de publication ou l’élément sélectionné en définit un plus strict ; le contrat le plus spécifique l’emporte.

N/A n’est pas un succès plus souple. Il n’est valide que lorsque l’élément ne s’applique vraiment pas — par exemple, aucune redirection n’est nécessaire car aucune URL n’est remplacée — et l’enregistrement en indique la raison. Une exception doit nommer la règle modifiée, la raison commerciale, le risque, l’approbateur, le propriétaire de la correction et la date d’expiration. L’autorité de mise en ligne la signe ; le relecteur QA ne s’auto-approuve pas.

Livrable : l’enregistrement de réussite

Attachez un enregistrement immuable au candidat exact. Un audit ultérieur doit pouvoir distinguer « jamais vérifié » de « vérifié et réussi sous la version 1 de la spécification ». Stockez des champs structurés plutôt qu’une capture d’écran de coches vertes.

Chemin de la page / canonique :
ID du candidat à la mise en ligne ou hash de contenu :
Type de publication et entité :
Version de la spécification :
Responsable QA :
Autorité de mise en ligne :
Début / fin (horodatage) :

Contrôles :
- Groupe / élément :
- Résultat : PASS | FAIL | N/A
- Preuve : sortie du validateur, emplacement source, destination ou observation
- Vérifié par / à :

Exceptions :
- Règle et périmètre :
- Raison et risque :
- Approbateur :
- Propriétaire de la correction / expiration :

Décision : PASS — PUBLIER | FAIL — BLOQUER
Responsable de la vérification en direct et délai :
Date de prochaine relecture de maintenance :

Un enregistrement de réussite est en ajout seul. Une spécification ou un candidat modifié donne lieu à un nouvel audit, pas à une réécriture de l’historique.

Que se passe-t-il en cas d’échec

L’échec déclenche une boucle de correction, pas une négociation dans le fil de relecture.

1. Le responsable QA marque le candidat FAIL — BLOQUER, enregistre les preuves et s’arrête au point où continuer testerait une version certaine de changer.
2. Le propriétaire du contenu corrige les échecs de type de publication, d’éléments, de texte, de métadonnées et de preuves. Le propriétaire de la mise en œuvre corrige les échecs de schéma, de liens, de médias, de routage, de rendu et d’automatisation. Un spécialiste revérifie les affirmations dans son domaine.
3. Le correcteur identifie chaque surface modifiée. Le responsable QA relance l’élément échoué, ses éléments dépendants et tout groupe affecté par le changement. Une réponse réécrite, par exemple, rouvre les affirmations, la conformité des éléments, la parité du schéma et l’extraction IA.
4. Le responsable QA crée un nouveau résultat horodaté. La publication reste bloquée jusqu’à ce que chaque élément applicable réussisse et que chaque N/A ou exception ait une autorité valide.

L’auteur ne certifie pas sa propre correction. La QA possède l’enregistrement, la production possède les corrections, les spécialistes possèdent l’approbation du domaine et l’autorité de mise en ligne possède les exceptions.

Ce qui peut mal tourner

• Traiter le portail comme une relecture. La grammaire peut être parfaite tandis que la page utilise le mauvais type de publication, contredit son schéma ou ne peut pas être indexée.
• Tester la source au lieu du candidat de mise en ligne. Un Markdown valide ne prouve pas que les templates ont émis la canonique prévue, la structure accessible ou la mise en page responsive.
• Tout faire manuellement. Les relecteurs cliquent sur des contrôles déterministes à répétition jusqu’à ce qu’une échéance leur apprenne à sauter la liste.
• Tout automatiser. Un validateur vert ne peut pas décider si les preuves soutiennent une affirmation causale ou si une comparaison répond à la décision du lecteur.
• Accepter « sera corrigé après le lancement ». Cela transforme un portail pré-publication en un backlog non documenté et efface le sens de PASS.
• Permettre à la même personne d’implémenter et d’approuver. L’auto-relecture manque les présupposés car le relecteur se souvient du comportement prévu plutôt que d’observer la sortie réelle.

Transfert

L’état suivant est la publication et la vérification en direct. La QA remet le candidat approuvé, l’enregistrement PASS, la route canonique, la carte de redirection, la fenêtre de mise en ligne et les exceptions approuvées. Le publiant retourne l’URL en direct et l’heure de déploiement ; le responsable de la vérification en direct répète les contrôles de statut, canonique, indexabilité, redirections, schéma, liens, médias, mobile et appel à l’action.

Si la production diffère, les contrôles concernés sont rouverts. Si elle correspond, ajoutez l’URL en direct et les preuves sans écraser le résultat du candidat. Les audits ultérieurs utilisent la version de spécification stockée pour distinguer une dérive d’un standard modifié.

FAQ

Foire aux questions

PASS signifie que le candidat est conforme au contrat actuel avec des preuves inspectables. Tout le reste est un blocage. L’appel à l’action de clôture de la mise en page academy suit cette FAQ.