SEO-checklist voor publicatie

Pre-publish kwaliteitsborging (QA) is de laatste release-gate in het SEO-proces . Het is waar drie contracten samenkomen: conformiteit met het berichttype, correct gebruik van elementen en voltooiing van het voorafgaande onderzoek, bewijsvoering, implementatie en review-werk. Een pagina die bij een toepasselijk item faalt, wordt teruggestuurd voor correctie.

Gate: definitieve pre-publish QA. Tijdsbox: 60–90 minuten voor een standaardpagina; voeg specialistische tijd toe voor gereguleerde, beveiligings-, financiële, medische of technisch consequente beweringen. Eigenaar: één redacteur, content lead of SEO lead die niet de uiteindelijke implementatie heeft gedaan en bevoegdheid heeft om release te blokkeren.

Een zachte checklist is geen checklist omdat “grotendeels klaar” geen vaste betekenis heeft. Onder tijdsdruk wordt vrijblijvende formulering een geheugensteun en verdwijnen moeilijke controles. Benoem de release-autoriteit vóór aanvang van de QA. De QA-eigenaar kan een pagina laten slagen of falen; alleen de genoemde hoofdredacteur, SEO lead of gelijkwaardige kan een schriftelijke uitzondering goedkeuren of een item als niet van toepassing verklaren. Zij kunnen geen valse bewering, ontbrekend verplicht element, placeholder-asset, kapotte canoniek of geblokkeerde indexeerbaarheid negeren om een deadline te halen.

Waarom deze gate bestaat en waarom hij hier wordt uitgevoerd

Deze gate verbruikt de goedgekeurde post-type-specificatie, elementcontracten, bronregistratie, definitieve tekst, geïmplementeerde kandidaat en specialistische goedkeuringen. Hij wordt uitgevoerd nadat deze invoer is bevroren, omdat QA geen bewegend doelwit kan verifiëren, en vóór publicatie omdat een defect kan worden gekopieerd zodra de URL live is.

Eerdere QA certificeert een concept dat kan veranderen. Overslaan ervan laat latere auditors niet in staat om paginadrift, een gewijzigde specificatie en een nooit gecontroleerde pagina te onderscheiden. QA na publicatie maakt goedkope correcties tot publieke defecten.

Invoer en uitvoer

De uitvoer is een contract, geen chatbericht. De uitgever moet erop kunnen handelen zonder de review te reconstrueren.

De checklist

Elk item hieronder bevat de actie, reden, methode, tool en waarneembare gereed-voorwaarde. “SEO gecontroleerd” of “ziet er goed uit” is nooit aanvaardbaar bewijs.

1. Post-type conformiteit

Bevestig het geselecteerde post-type en de reikwijdte. Wat: koppel de kandidaat aan één item in de post-type bibliotheek en verwijder materiaal dat bij een verwant type hoort. Waarom: paginatype bepaalt intentie, structuur, bewijs en conversiegedrag. Hoe: label elke sectie met de lezersbeslissing die het ondersteunt en vergelijk met het doel en de uitsluitingen van het type. Tool: goedgekeurde brief, onderwerpskaart en post-type-pagina’s. Gereed wanneer: exact één primair type is geregistreerd, de opening, body en CTA dienen dat type, en er zijn nul secties die uitsluitend bestaan voor de taak van een ander type.

Traceer vereiste structuur en woordbanden. Wat: koppel elke vereiste sectie aan de gerenderde kandidaat en tel de woorden ervan tegen de gespecificeerde band. Waarom: ontbrekende secties creëren onbeantwoorde vragen, terwijl onbeheerste lengte gaten achter volume verbergt. Hoe: gebruik een vereiste-naar-kopmatrix en geautomatiseerde tellingen, inspecteer vervolgens grensgevallen handmatig. Tool: post-type-specificatie, bron en gerenderde pagina. Gereed wanneer: nul vereiste secties ontbreken en elke sectie binnen het opgegeven minimum en maximum valt.

2. Elementconformiteit

Verifieer elementen, posities en parameters. Wat: vergelijk de elementenkaart met bron en render. Waarom: positie en velden maken deel uit van de functie; een begraven direct antwoord antwoordt niet langer eerst, en misvormde parameters kunnen output breken. Hoe: inspecteer van boven naar beneden en valideer toegestane velden, waarden, nesting en syntaxis. Tool: elementspecificaties, validator en browser. Gereed wanneer: elk verplicht element op de vereiste positie staat, elke parameter geldig is en er geen onverklaarbaar duplicaat overblijft.

Handhaaf getypeerde-element-precedentie. Wat: pas de element-schrijfregels toe waar een passage een geregistreerd doel heeft. Waarom: vrije tekst kan er vergelijkbaar uitzien, maar kan niet de componentidentiteit, velden, toegankelijkheidsgedrag of gestructureerde output dragen. Hoe: geef de taak van elk blok aan als een werkwoord — definiëren, waarschuwen, vergelijken, instrueren, samenvatten — en controleer op een bijpassend element. Tool: elementenbibliotheek en broninspecteur. Gereed wanneer: nul passages vrije tekst gebruiken waar een getypeerd element verplicht is.

3. Contentkwaliteit

Test het antwoord in isolatie. Wat: lees het direct antwoordblok zonder de kop of omliggende alinea’s. Waarom: zoek- en AI-retrievalsystemen kunnen alleen die passage extraheren. Hoe: controleer of het het onderwerp noemt, de vraag beantwoordt, noodzakelijke kwalificatie bevat en niet vertrouwt op “dit”, “het” of “zoals hierboven”. Tool: geïsoleerde tekstweergave en menselijke reviewer. Gereed wanneer: het antwoord zelfstandig, accuraat en binnen de gespecificeerde band van 40–60 woorden is wanneer dat element vereist is.

Verifieer beweringen, taal en uniciteit. Wat: traceer materiële beweringen naar bewijs, leg jargon uit bij eerste gebruik en vergelijk de kandidaat met pagina’s die dezelfde intentie dienen. Waarom: ongefundeerde beweringen schaden vertrouwen, terwijl bijna-duplicaten concurreren en afdrijven. Hoe: markeer namen, data, getallen, causale beweringen, productgedrag en gelijkeniskandidaten; ondersteun, kwalificeer, consolideer of verwijder ze. Tool: bewijsregister, primaire bronnen, sitezoekopdracht en gelijkenisrapport. Gereed wanneer: nul materiële beweringen zonder ondersteuning zijn, nul specialistische termen onverklaard blijven en geen bestaande pagina dezelfde intentie en reikwijdte beantwoordt zonder een consolidatieplan.

4. Frontmatter

Valideer identiteits- en voorvertoningsvelden. Wat: pas de frontmatter-specificatie toe op titel, beschrijving, keywords, entity en post-type-koppelingen. Waarom: deze velden sturen routering, voorvertoningen, schema’s en relaties aan zonder de body te lezen. Hoe: voer veld- en lengtevalidatie uit, vergelijk vervolgens de betekenis met de zichtbare pagina. Tool: frontmatter-linter en menselijke voorvertoning. Gereed wanneer: de titel uniek en accuraat is, beschrijving 150–160 tekens bevat, keywords 6–8 relevante items bevatten en entity overeenkomt met het post-type-contract.

Verifieer governance- en FAQ-velden. Wat: controleer data, auteur, reviewer, eigenaarschap en zichtbare FAQ-structuur tegen frontmatter. Waarom: anonieme registraties voorkomen verantwoordelijkheid, terwijl FAQ-drift zichtbare en gestructureerde antwoorden laat afwijken. Hoe: vergelijk velden met het releasetraject en genormaliseerde zichtbare tekst. Tool: bronparser, tracker en gerenderde pagina. Gereed wanneer: vereiste data en eigenaren geldig zijn, de menselijke reviewer waar nodig genoemd is, het FAQ-aantal voldoet aan het typeminimum, elk paar overeenkomt en er geen verborgen of lege items overblijven.

5. Gestructureerde data

Vereis het juiste schema. Wat: bevestig dat toepasselijke schemamarkering bestaat voor de pagina en de zichtbare elementen. Waarom: ontbrekende of generieke markering gooit machineleesbare betekenis weg die het contentmodel al biedt. Hoe: vergelijk uitgezonden typen en eigenschappen met de post-type- en elementcontracten. Tool: gerenderde HTML en schemavalidator. Gereed wanneer: elk vereist schematype één keer aanwezig is, vereiste eigenschappen zijn ingevuld en geen niet-toepasselijk type wordt uitgezonden.

Valideer pariteit, niet alleen syntaxis. Wat: vergelijk schemanamen, data, auteur, entiteit, FAQ, stappen en beweringen met zichtbare content. Waarom: geldige syntaxis kan nog steeds onzichtbare of tegenstrijdige informatie beschrijven. Hoe: valideer JSON-LD, vergelijk vervolgens waarden met de pagina. Tool: gestructureerde-data-test en menselijke review. Gereed wanneer: er nul fouten zijn en nul feiten in schema die de zichtbare content tegenspreken of overschrijden.

6. Interne koppelingen

Link omhoog en naar buiten. Wat: bied een route naar de relevante pijler en contextuele routes naar gerelateerde knooppunten. Waarom: hiërarchie helpt lezers en crawlers begrijpen waar de pagina thuishoort, terwijl laterale links de taak van de lezer voortzetten. Hoe: koppel elke interne link aan een echte volgende vraag in plaats van een quotum te vullen. Tool: linkgraaf en gerenderde pagina. Gereed wanneer: de pagina ten minste één link heeft naar zijn pijler, ten minste één relevante laterale link waar een gerelateerd knooppunt bestaat, en ten minste één bestaande pagina ernaar linkt voor of bij publicatie, zodat deze niet wees blijft.

Inspecteer bestemmingen en ankers. Wat: open elke bestemming en beoordeel de ankervaste tekst . Waarom: een plausibele URL kan ontbreken, omgeleid of niet-gerelateerd zijn, en generieke labels verbergen het doel van de bestemming. Hoe: voer een interne-link-checker uit, inspecteer vervolgens handmatig ankers in zinscontext. Tool: crawler en browser. Gereed wanneer: nul interne links een fout retourneren, elke bestemming de omliggende bewering ondersteunt en er geen losstaand “klik hier”, onbewerkte URL of misleidende exact-match-anker overblijft.

7. Media

Verifieer assets, alternatieven en actualiteit. Wat: bevestig dat elke afbeelding bestaat, betekenisvolle alt-tekst of een gerechtvaardigd leeg alternatief heeft en de huidige interface weerspiegelt. Waarom: kapotte, vage, placeholder of verouderde media verwijdert informatie en kan instructies onbruikbaar maken. Hoe: schakel afbeeldingen uit, inspecteer paden, reproduceer productstappen en vergelijk labels, waarden, bijsnijding en redactie. Tool: asset-checker, toegankelijkheidsaudit, live product en browser. Gereed wanneer: nul assets ontbreken of placeholders zijn, alternatieven accuraat zijn en elke schermafbeelding de huidige stap weergeeft.

8. Technische release

Verifieer routering, indexeerbaarheid en vervanging. Wat: controleer slug, één zelfverwijzende canonieke URL , status, robots-gedrag, indexeerbaarheid en redirects. Waarom: content kan niet presteren op de verkeerde route, achter noindex of nadat oude URL’s zijn achtergelaten. Hoe: inspecteer de gerenderde head en response, vergelijk het register en volg elke vervangen route. Tool: header-checker, redirect-kaart, broninspecteur en URL-inspectie. Gereed wanneer: de goedgekeurde URL 200 retourneert met één beoogde canoniek en geen blokkade; elke vervangen URL neemt één permanente hop naar de dichtstbijzijnde geldige vervanging.

Test mobiele stabiliteit. Wat: inspecteer smal-weergave lezen, interactie, overflow en Cumulative Layout Shift . Waarom: componenten die op desktop werken, kunnen bedieningselementen verbergen, tabellen afknippen of content verplaatsen terwijl media laadt. Hoe: test representatieve mobiele breedtes en laad de pagina met throttling. Tool: browser-apparaatmodus en prestatieverslag. Gereed wanneer: alle content en bedieningselementen bruikbaar blijven zonder horizontale paginaoverflow en de gemeten CLS 0,1 of lager is.

9. AI-gereedheid

Test extractie en initiële HTML. Wat: inspecteer antwoorden, definities, kernfeiten, vergelijkingen en conclusies als onafhankelijke passages in server-geleverde HTML. Waarom: retrievalsystemen kunnen één passage selecteren en mogelijk geen client-side code uitvoeren. Hoe: haal initiële HTML op, verwijder omliggende context en controleer entiteitsnamen, kwalificaties, eenheden en voornaamwoorden. Tool: HTML-fetch, passage-extractor, browser en AmICited-audit. Gereed wanneer: elk prioriteitsfeit aanwezig is zonder JavaScript en zijn onderwerp, betekenis en beperkingen alleen behoudt.

Stel procedurele structuur bloot. Wat: verifieer dat FAQ-paren en geordende stappen zijn gecodeerd als herkenbare velden en zichtbaar blijven. Waarom: koppen en opgemaakte vakken kunnen er correct uitzien terwijl machines ongestructureerde proza ontvangen. Hoe: vergelijk element-output, toegankelijke structuur en schema met de zichtbare volgorde. Tool: toegankelijkheidsboom en gestructureerde-data-validator. Gereed wanneer: elke vereiste FAQ machineleesbaar is als vraag-antwoordpaar en elke vereiste procedure geordende stappen behoudt in zichtbare en gestructureerde output.

Tools in AmICited

Gebruik het product om de kandidaat te inspecteren en overdrachtsbewijs vast te stellen; het vervangt geen menselijk oordeel.

1. Open de agent-gereedschapsaudit samen met AI-toegankelijkheid en agent-gereedheid om toegankelijkheid, crawler-bereikbaarheid, sitemapdekking en agent-leesbare content te inspecteren.
2. Inspecteer de kandidaat-URL met URL-inspectie om indexstatus, mobiele bruikbaarheid en rich results-oordeel te verifiëren. Wijs live-inspectie toe in de overdracht voor een nieuwe URL.
3. Open de versheidsaudit met Contentversheid om tijdgevoelige pagina’s een onderhoudssignaal en volgende reviewdatum te geven. Geschiedenis begint wanneer tracking begint; geen geschiedenis betekent geen verandering.
4. Gebruik SEO MCP via de werkruimteverbinding voor herhaalbare alleen-lezen URL-, versheids-, Web Vitals- en toegankelijkheidscontroles. Bewaar de output of run-identifier.

Automatisering: script de deterministische controles, behoud menselijke beslissingen

Een controle die geschreven kan worden maar handmatig blijft, zal onder druk worden overgeslagen. Automatiseer stabiele, machine-waarneembare resultaten; vereis een mens voor doel, waarheid en context.

Automatisering schrijft bewijs, geen goedkeuring. Falen blokkeert de gate; een geslaagd script passeert de menselijke kolommen niet.

Beslissingsregels

“Slecht” moet waarneembaar zijn. Gebruik deze drempels tenzij het geselecteerde post-type of element een strengere definieert; het meer specifieke contract wint.

NVT is geen zachtere goedkeuring. Het is alleen geldig wanneer het item echt niet van toepassing is — bijvoorbeeld er is geen redirect nodig omdat er geen URL wordt vervangen — en de registratie vermeldt waarom. Een uitzondering moet de gewijzigde regel, zakelijke reden, risico, goedkeurder, correctie-eigenaar en vervaldatum noemen. De release-autoriteit ondertekent het; de QA-reviewer keurt het niet zelf goed.

Opleverbaar: de goedkeuringsregistratie

Voeg één onveranderlijke registratie toe aan de exacte kandidaat. Een latere audit moet “nooit gecontroleerd” kunnen onderscheiden van “gecontroleerd en goedgekeurd onder specificatieversie 1.” Sla gestructureerde velden op in plaats van een schermafbeelding met groene vinkjes.

Paginapad / canoniek:
Releasekandidaat-ID of content-hash:
Post-type en entiteit:
Specificatieversie:
QA-eigenaar:
Release-autoriteit:
Gestart / voltooid (tijdstempel):

Controles:
- Groep / item:
- Resultaat: PASS | FAIL | NVT
- Bewijs: validatoruitvoer, bronlocatie, bestemming of observatie
- Gecontroleerd door / om:

Uitzonderingen:
- Regel en reikwijdte:
- Reden en risico:
- Goedkeurder:
- Correctie-eigenaar / vervaldatum:

Beslissing: PASS — PUBLICEREN | FAIL — WACHTEN
Live-verificatie-eigenaar en deadline:
Volgende onderhoudsreviewdatum:

Een goedkeuringsregistratie is alleen-toevoegen. Een gewijzigde specificatie of kandidaat krijgt een nieuwe audit, geen herschreven geschiedenis.

Wat gebeurt er bij falen

Falen start een correctielus, geen onderhandeling in de reviewthread.

1. De QA-eigenaar markeert de kandidaat FAIL — WACHTEN, registreert bewijs en stopt op het punt waar doorgaan een versie zou testen die zeker zal veranderen.
2. De content-eigenaar repareert post-type-, element-, tekst-, metadata- en bewijsfouten. De implementatie-eigenaar repareert schema-, link-, media-, routerings-, renderings- en automatiseringsfouten. Een specialist controleert beweringen opnieuw in hun domein.
3. De hersteller identificeert elk veranderd oppervlak. De QA-eigenaar voert het mislukte item, de afhankelijke items en elke groep die door de wijziging wordt beïnvloed, opnieuw uit. Een herschreven antwoord heropent bijvoorbeeld beweringen, elementconformiteit, schemapariteit en AI-extractie.
4. De QA-eigenaar maakt een nieuw resultaat met tijdstempel. Publicatie blijft geblokkeerd tot elk toepasselijk item slaagt en elke NVT of uitzondering geldige autoriteit heeft.

De auteur certificeert zijn eigen correctie niet. QA is eigenaar van de registratie, productie is eigenaar van correcties, specialisten zijn eigenaar van domeingoedkeuring en de release-autoriteit is eigenaar van uitzonderingen.

Wat er misgaat

• De gate behandelen als proeflezen. Grammatica kan foutloos zijn terwijl de pagina het verkeerde post-type gebruikt, het schema tegenspreekt of niet kan worden geïndexeerd.
• De bron testen in plaats van de releasekandidaat. Geldige Markdown bewijst niet dat templates de beoogde canoniek, toegankelijke structuur of responsieve layout hebben uitgezonden.
• Elk item handmatig maken. Reviewers klikken herhaaldelijk op deterministische controles totdat een deadline hen leert de lijst over te slaan.
• Elk item geautomatiseerd maken. Een groene validator kan niet beslissen of bewijs een causale bewering ondersteunt of of een vergelijking de beslissing van de lezer beantwoordt.
• Accepteren van “wordt na lancering opgelost.” Dat verandert een pre-publish-gate in een ongedocumenteerde backlog en wist de betekenis van PASS.
• Dezelfde persoon laten implementeren en goedkeuren. Zelfreview mist aannames omdat de reviewer het beoogde gedrag onthoudt in plaats van de werkelijke output te observeren.

Overdracht

De volgende toestand is publicatie en live-verificatie. QA draagt de goedgekeurde kandidaat, PASS-registratie, canonieke route, redirect-kaart, releasevenster en goedgekeurde uitzonderingen over. De uitgever retourneert de live URL en implementatietijd; de live-verificatie-eigenaar herhaalt status-, canoniek-, indexeerbaarheids-, redirect-, schema-, link-, media-, mobiele- en CTA-controles.

Als productie afwijkt, worden betrokken controles heropend. Als het overeenkomt, voeg dan de live URL en het bewijs toe zonder het kandidaatresultaat te overschrijven. Latere audits gebruiken de opgeslagen specificatieversie om drift van een gewijzigde standaard te onderscheiden.

FAQ

Veelgestelde vragen

PASS betekent dat de kandidaat voldoet aan het huidige contract met inspecteerbaar bewijs. Al het andere is een wacht. De afsluitende CTA van de academy-layout volgt deze FAQ.