Sjekkliste for kvalitetssikring før publisering (SEO)

Kvalitetssikring (QA) før publisering er den endelige publiseringsporten i SEO-prosessen . Det er her tre kontrakter møtes: samsvar med innholdstype, korrekt elementbruk, og fullføring av det foregående forsknings-, dokumentasjons-, implementerings- og gjennomgangsarbeidet. En side som ikke består et gjeldende punkt, returneres for retting.

Port: endelig QA før publisering. Tidsramme: 60–90 minutter for en standardside; legg til spesialisttid for regulerte, sikkerhetsmessige, finansielle, medisinske eller teknisk betydningsfulle påstander. Eier: én redaktør, innholdsansvarlig eller SEO-ansvarlig som ikke utførte den endelige implementeringen og har myndighet til å blokkere publisering.

En myk sjekkliste er ikke en sjekkliste fordi «stort sett ferdig» ikke har noen stabil betydning. Under tidsfrist blir valgfrie formuleringer et huskeredskap, og vanskelige kontroller forsvinner. Navngi publiseringsansvarlig før QA starter. QA-eieren kan godkjenne eller avvise; bare den navngitte innholdssjefen, SEO-ansvarlig eller tilsvarende kan godkjenne et skriftlig unntak eller erklære et punkt uaktuelt. De kan ikke frafalle en uriktig påstand, manglende påkrevd element, plassholderressurs, ødelagt kanonisk eller blokkert indekserbarhet for å overholde en tidsfrist.

Hvorfor denne porten finnes, og hvorfor den kjører her

Denne porten bruker den godkjente innholdstype-spesifikasjonen, elementkontraktene, kildejournalen, endelig kopi, implementert kandidat og spesialistgodkjenninger. Den kjører etter at disse inndataene er fryst fordi QA ikke kan verifisere et bevegelig mål, og før publisering fordi en feil kan kopieres så snart URL-en er aktiv.

Tidligere QA sertifiserer et utkast som kan endres. Å hoppe over det gjør at senere revisorer ikke kan skille mellom sideendringer, en endret spesifikasjon og en side som aldri ble kontrollert. QA etter publisering gjør billige rettinger til offentlige feil.

Inndata og utdata

Resultatet er en kontrakt, ikke en chattemelding. Publisøren må kunne handle på den uten å rekonstruere gjennomgangen.

Sjekklisten

Hvert punkt nedenfor inkluderer handling, begrunnelse, metode, verktøy og observerbar «ferdig når»-betingelse. «SEO-sjekket» eller «ser bra ut» er aldri akseptabelt bevis.

1. Samsvar med innholdstype

Bekreft valgt innholdstype og omfang. Hva: match kandidaten mot én oppføring i biblioteket for innholdstyper og fjern innhold som tilhører en søskentype. Hvorfor: sidetype avgjør intensjon, struktur, bevis og konverteringsatferd. Hvordan: merk hver seksjon med leserbeslutningen den støtter, og sammenlign med typeens formål og unntak. Verktøy: godkjent beskrivelse, emnekart og innholdstype-sider. Ferdig når: nøyaktig én primærtype er registrert, innledning, brødtekst og CTA tjener den, og ingen seksjoner eksisterer utelukkende for en annen types oppgave.

Spore påkrevd struktur og ordgrenser. Hva: kartlegg hver påkrevd seksjon til den gjengitte kandidaten og tell ordene opp mot angitt grense. Hvorfor: manglende seksjoner skaper ubesvarte spørsmål, mens ukontrollert lengde skjuler hull bak volum. Hvordan: bruk en krav-til-overskrift-matrise og automatiserte tellinger, og inspiser deretter grensetilfeller manuelt. Verktøy: innholdstype-spesifikasjon, kilde og gjengitt side. Ferdig når: ingen påkrevde seksjoner mangler, og hver seksjon er innenfor sitt angitte minimum og maksimum.

2. Elementsamsvar

Verifiser elementer, plasseringer og parametere. Hva: sammenlign elementkartet med kilde og gjengivelse. Hvorfor: plassering og felt er del av funksjonen; et begravd direkte svar svarer ikke lenger først, og feilformede parametere kan ødelegge utdata. Hvordan: inspiser fra topp til bunn og valider tillatte felt, verdier, nesting og syntaks. Verktøy: element-spesifikasjoner, valideringsverktøy og nettleser. Ferdig når: hvert obligatoriske element er på sin påkrevde plassering, hver parameter er gyldig, og ingen uforklarte duplikater gjenstår.

Håndhev prioritet for typede elementer. Hva: bruk skrivereglene for elementer der en passasje har et registrert formål. Hvorfor: fritekst kan se lik ut, men kan ikke bære komponentidentiteten, feltene, tilgjengelighetsatferden eller strukturerte utdata. Hvordan: angi hver blokks jobb som et verb — definer, advar, sammenlign, instruer, oppsummer — og sjekk om det finnes et matchende element. Verktøy: elementbibliotek og kildeinspektør. Ferdig når: ingen passasjer bruker fritekst der et typet element er obligatorisk.

3. Innholdskvalitet

Test svaret isolert. Hva: les den direkte svar-blokken uten overskriften eller omkringliggende avsnitt. Hvorfor: søke- og AI-hentingssystemer kan hente ut kun den passasjen. Hvordan: sjekk at den navngir emnet, svarer på spørsmålet, inkluderer nødvendig kvalifisering, og ikke er avhengig av «dette», «det» eller «som ovenfor». Verktøy: isolert tekstvisning og menneskelig kontrollør. Ferdig når: svaret er selvstendig, nøyaktig og innenfor sin spesifiserte grense på 40–60 ord når dette elementet er påkrevd.

Verifiser påstander, språk og unikhet. Hva: spor vesentlige påstander til bevis, forklar fagsjargong ved første gangs bruk, og sammenlign kandidaten med sider som tjener samme intensjon. Hvorfor: uunderstøttede påstander skader tillit, mens nesten-duplikater konkurrerer og driver. Hvordan: marker navn, datoer, tall, årsakspåstander, produktatferd og likhetskandidater; støtt, kvalifiser, konsolider eller fjern dem. Verktøy: bevisregister, primærkilder, nettsidesøk og likhetsrapport. Ferdig når: ingen vesentlige påstander mangler støtte, ingen fagtermer forblir uforklart, og ingen eksisterende side svarer på samme intensjon og omfang uten en konsolideringsplan.

4. Frontmatter

Valider identitets- og forhåndsvisningsfelt. Hva: bruk frontmatter-spesifikasjonen på tittel, beskrivelse, nøkkelord, entity og innholdstype-koblinger. Hvorfor: disse feltene styrer ruting, forhåndsvisninger, skjemaer og relasjoner uten å lese brødteksten. Hvordan: kjør felt- og lengdevalidering, sammenlign deretter betydning med den synlige siden. Verktøy: frontmatter-linter og menneskelig forhåndsvisning. Ferdig når: tittelen er unik og nøyaktig, beskrivelsen er 150–160 tegn, nøkkelord inneholder 6–8 relevante oppføringer, og entity samsvarer med innholdstype-kontrakten.

Verifiser styrings- og FAQ-felt. Hva: sjekk datoer, forfatter, kontrollør, eierskap og synlig FAQ-struktur mot frontmatter. Hvorfor: anonyme poster forhindrer ansvarliggjøring, mens FAQ-drift gjør at synlige og strukturerte svar blir uenige. Hvordan: sammenlign felt med publiseringssporet og normalisert synlig tekst. Verktøy: kildeparser, sporingsverktøy og gjengitt side. Ferdig når: påkrevde datoer og eiere er gyldige, den menneskelige kontrolløren er navngitt der det kreves, FAQ-antall oppfyller typens minimum, hvert par matcher, og ingen skjulte eller tomme oppføringer gjenstår.

5. Strukturerte data

Krev riktig skjema. Hva: bekreft at gjeldende skjemamarkering finnes for siden og dens synlige elementer. Hvorfor: manglende eller generisk markering forkaster maskinlesbar mening som innholdsmodellen allerede gir. Hvordan: sammenlign utsendte typer og egenskaper med innholdstype- og elementkontraktene. Verktøy: gjengitt HTML og skjemavalideringsverktøy. Ferdig når: hver påkrevde skjematype er til stede én gang, påkrevde egenskaper er utfylt, og ingen ikke-gjeldende type sendes ut.

Valider paritet, ikke bare syntaks. Hva: sammenlign skjemanavn, datoer, forfatter, entitet, FAQ, trinn og påstander med synlig innhold. Hvorfor: gyldig syntaks kan fortsatt beskrive usynlig eller motstridende informasjon. Hvordan: valider JSON-LD, sammenlign deretter verdier med siden. Verktøy: strukturert-data-test og menneskelig gjennomgang. Ferdig når: det er null feil og null fakta i skjema som motsier eller overskrider synlig innhold.

6. Interne koblinger

Lenk opp og ut. Hva: sørg for en rute til den relevante hjørnesteinssiden og kontekstuelle ruter til relaterte noder. Hvorfor: hierarki hjelper lesere og gjennomsøkere med å forstå hvor siden hører hjemme, mens sidelange koblinger fortsetter leserens oppgave. Hvordan: kartlegg hver intern kobling til et genuint neste spørsmål i stedet for å fylle en kvote. Verktøy: koblingsgraf og gjengitt side. Ferdig når: siden har minst én kobling til sin hjørnesteinsside, minst én relevant sidelang kobling der en relatert node eksisterer, og minst én eksisterende side lenker inn til den før eller ved publisering, slik at den ikke blir foreldreløs.

Inspiser destinasjoner og ankere. Hva: åpne hver destinasjon og gjennomgå ankerteketen . Hvorfor: en plausibel URL kan være manglende, omdirigert eller urelatert, og generiske etiketter skjuler destinasjonens formål. Hvordan: kjør en internlenke-kontroll, inspiser deretter ankere manuelt i setningskontekst. Verktøy: gjennomsøker og nettleser. Ferdig når: ingen interne koblinger returnerer en feil, hver destinasjon støtter den omkringliggende påstanden, og ingen frittstående «klikk her», rå-URL eller misvisende eksakt-match-anker gjenstår.

7. Medier

Verifiser ressurser, alternativer og aktualitet. Hva: bekreft at hvert bilde eksisterer, har meningsfull alt-tekst eller et berettiget tomt alternativ, og gjenspeiler det gjeldende grensesnittet. Hvorfor: ødelagte, vage, plassholder- eller utdaterte medier fjerner informasjon og kan gjøre instruksjoner ubrukelige. Hvordan: deaktiver bilder, inspiser stier, reproduser produkttrinn, og sammenlign etiketter, verdier, beskjæring og sladding. Verktøy: ressurskontroll, tilgjengelighetsrevisjon, levende produkt og nettleser. Ferdig når: ingen ressurser mangler eller er plassholdere, alternativer er nøyaktige, og hvert skjermbilde representerer det gjeldende trinnet.

8. Teknisk publisering

Verifiser ruting, indekserbarhet og erstatning. Hva: sjekk slug, én selvrefererende kanonisk URL , status, robots-atferd, indekserbarhet og omdirigeringer. Hvorfor: innhold kan ikke prestere på feil rute, bak noindex, eller etter at gamle URL-er blir etterlatt. Hvordan: inspiser gjengitt head og respons, sammenlign registeret, og følg hver erstattet rute. Verktøy: header-kontroll, omdirigeringskart, kildeinspektør og URL-inspeksjon. Ferdig når: den godkjente URL-en returnerer 200 med én tiltenkt kanonisk og ingen blokkering; hver erstattet URL tar ett permanent hopp til nærmeste gyldige erstatning.

Test mobil stabilitet. Hva: inspiser smal-bredde-lesing, interaksjon, overløp og Kumulativ Layout Shift . Hvorfor: komponenter som fungerer på skrivebord kan skjule kontroller, klippe tabeller eller flytte innhold når medier lastes. Hvordan: test representative mobile bredder og last siden med hastighetsbegrensning. Verktøy: nettleserens enhetsmodus og ytelsesrapport. Ferdig når: alt innhold og alle kontroller forblir brukbare uten horisontalt sideoverløp, og målt CLS er 0,1 eller lavere.

9. AI-beredskap

Test uthenting og innledende HTML. Hva: inspiser svar, definisjoner, nøkkelfakta, sammenligninger og konklusjoner som uavhengige passasjer i server-levert HTML. Hvorfor: hentingssystemer kan velge én passasje og kan ikke utføre klientsidekode. Hvordan: hent innledende HTML, fjern omkringliggende kontekst, og sjekk entitetsnavn, kvalifikatorer, enheter og pronomener. Verktøy: HTML-henting, passasje-uthenter, nettleser og AmICited-revisjon. Ferdig når: hvert prioritetsfaktum er til stede uten JavaScript og beholder sitt emne, betydning og begrensninger alene.

Eksponer prosedyrestruktur. Hva: verifiser at FAQ-par og ordnede trinn er kodet som gjenkjennelige felt og forblir synlige. Hvorfor: overskrifter og stilte bokser kan se riktige ut mens maskiner mottar ustrukturert prosa. Hvordan: sammenlign elementutdata, tilgjengelig struktur og skjema med den synlige sekvensen. Verktøy: tilgjengelighetstre og strukturert-data-valideringsverktøy. Ferdig når: hver påkrevde FAQ er maskinlesbar som et spørsmål-svar-par, og hver påkrevd prosedyre bevarer ordnede trinn i synlig og strukturert utdata.

Verktøy i AmICited

Bruk produktet for å inspisere kandidaten og etablere overleveringsbevis; det erstatter ikke menneskelig dømmekraft.

1. Åpne agentberedskapsrevisjonen sammen med AI-tilgjengelighet og agentberedskap for å inspisere tilgjengelighet, gjennomsøkingsrekkevidde, nettstedkartdekning og agentlesbart innhold.
2. Inspiser kandidatens URL med URL-inspeksjon for å verifisere indeksstatus, mobiltilpassing og vurdering av rike resultater. Tildel sanntidsinspeksjon i overleveringen for en ny URL.
3. Åpne friskhetsrevisjonen med Innholdsfriskhet for å gi tidsfølsomme sider et vedlikeholdssignal og neste revisjonsdato. Historikk starter når sporing begynner; ingen historikk betyr ikke ingen endring.
4. Bruk SEO MCP gjennom arbeidsområde-tilkoblingen for gjentagbare skrivebeskyttede URL-, friskhets-, Web Vitals- og tilgjengelighetskontroller. Lagre utdata eller kjøringsidentifikator.

Automatisering: skript de deterministiske kontrollene, bevar menneskelige beslutninger

En kontroll som kan skriptes, men forblir manuell, vil bli hoppet over under press. Automatiser stabile, maskinobserverbare resultater; krev et menneske for formål, sannhet og kontekst.

Automatisering skriver bevis, ikke godkjenning. Feil blokkerer porten; et bestått skript består ikke de menneskelige kolonnene.

Beslutningsregler

«Dårlig» må være observerbart. Bruk disse tersklene med mindre den valgte innholdstypen eller elementet definerer en strengere; den mer spesifikke kontrakten vinner.

IKKE AKTUELL er ikke en mykere bestått. Det er kun gyldig når punktet virkelig ikke gjelder — for eksempel, ingen omdirigering er nødvendig fordi ingen URL blir erstattet — og posten angir hvorfor. Et unntak må navngi den endrede regelen, forretningsgrunn, risiko, godkjenner, rettelseseier og utløpsdato. Publiseringsansvarlig signerer det; QA-kontrolløren godkjenner det ikke selv.

Leveranse: godkjenningsposten

Vedlegg én uforanderlig post til den nøyaktige kandidaten. En senere revisjon må kunne skille «aldri kontrollert» fra «kontrollert og bestått under spesifikasjonsversjon 1.» Lagre strukturerte felt i stedet for et skjermbilde med grønne hakemerker.

Sidesti / kanonisk:
Publiseringskandidat-ID eller innholdshash:
Innholdstype og entitet:
Spesifikasjonsversjon:
QA-eier:
Publiseringsansvarlig:
Startet / fullført (tidsstempel):

Kontroller:
- Gruppe / punkt:
- Resultat: BESTÅTT | IKKE BESTÅTT | IKKE AKTUELL
- Bevis: validatorutdata, kildeplassering, destinasjon eller observasjon
- Kontrollert av / klokken:

Unntak:
- Regel og omfang:
- Årsak og risiko:
- Godkjenner:
- Rettelseseier / utløp:

Beslutning: BESTÅTT — PUBLISER | IKKE BESTÅTT — HOLD
Eier av sanntidsverifisering og tidsfrist:
Neste vedlikeholdsgjennomgangsdato:

En godkjenningspost er skrivebeskyttet. En endret spesifikasjon eller kandidat får en ny revisjon, ikke omskrevet historikk.

Hva skjer ved feil

Feil starter en rettelsessløyfe, ikke en forhandling i gjennomgangstråden.

1. QA-eieren merker kandidaten IKKE BESTÅTT — HOLD, registrerer bevis og stopper på det punktet hvor videreføring ville teste en versjon som sikkert vil endres.
2. Innholdseieren fikser feil i innholdstype, elementer, kopi, metadata og bevis. Implementeringseieren fikser feil i skjema, koblinger, medier, ruting, gjengivelse og automatisering. En spesialist sjekker påstander på nytt innen sitt fagområde.
3. Fikseren identifiserer hver endrede overflate. QA-eieren kjører på nytt det mislykkede punktet, dets avhengige punkter, og enhver gruppe som er påvirket av endringen. Et omskrevet svar, for eksempel, åpner påstands-, elementsamsvars-, skjemaparitets- og AI-uthentingskontrollene på nytt.
4. QA-eieren oppretter et nytt tidsstemplet resultat. Publisering forblir blokkert inntil hvert gjeldende punkt består og hvert IKKE AKTUELL eller unntak har gyldig myndighet.

Forfatteren sertifiserer ikke sin egen retting. QA eier posten, produksjon eier rettinger, spesialister eier fagområdegodkjenning, og publiseringsansvarlig eier unntak.

Hva går galt

• Å behandle porten som korrekturlesing. Grammatikk kan være feilfri samtidig som siden bruker feil innholdstype, motsier skjemaet eller ikke kan indekseres.
• Å teste kilde i stedet for publiseringskandidaten. Gyldig Markdown beviser ikke at malene sendte ut den tiltenkte kanoniske, tilgjengelige strukturen eller responsive layouten.
• Å gjøre hvert punkt manuelt. Kontrollører klikker seg gjentatte ganger gjennom deterministiske kontroller inntil en tidsfrist lærer dem å hoppe over listen.
• Å gjøre hvert punkt automatisert. En grønn validator kan ikke avgjøre om bevis støtter en årsakspåstand eller om en sammenligning svarer på leserens beslutning.
• Å akseptere «fikser etter lansering.» Det gjør en port før publisering om til en udokumentert oppgavebeholdning og visker bort betydningen av BESTÅTT.
• Å la samme person implementere og godkjenne. Selv-gjennomgang går glipp av antakelser fordi kontrolløren husker tiltenkt atferd i stedet for å observere faktisk utdata.

Overlevering

Neste tilstand er publisering og sanntidsverifisering. QA overleverer den godkjente kandidaten, BESTÅTT-posten, kanonisk rute, omdirigeringskart, publiseringsvindu og godkjente unntak. Publisøren returnerer den levende URL-en og distribusjonstiden; eieren av sanntidsverifisering gjentar kontroller av status, kanonisk, indekserbarhet, omdirigeringer, skjema, koblinger, medier, mobil og CTA.

Hvis produksjonen avviker, åpnes berørte kontroller på nytt. Hvis den samsvarer, legg til den levende URL-en og bevis uten å overskrive kandidatens resultat. Senere revisjoner bruker den lagrede spesifikasjonsversjonen for å skille drift fra en endret standard.

FAQ

Ofte stilte spørsmål

Bestått betyr at kandidaten samsvarer med gjeldende kontrakt med inspiserbare bevis. Alt annet er et hold. Akademi-layoutens avsluttende CTA følger denne FAQ-en.