Checklista för SEO före publicering

Kvalitetssäkring (QA) före publicering är den sista lanseringsgrinden i SEO-processen . Det är här tre kontrakt möts: överensstämmelse med inläggstyp, korrekt elementanvändning och slutförandet av föregående forskning, bevis, implementation och granskningsarbete. En sida som inte klarar någon tillämplig punkt skickas tillbaka för korrigering.

Grind: slutgiltig QA före publicering. Tidsram: 60–90 minuter för en standardsida; lägg till specialisttid för reglerade, säkerhets-, ekonomiska, medicinska eller tekniskt betydelsefulla påståenden. Ägare: en redaktör, innehållsansvarig eller SEO-ansvarig som inte gjorde den slutgiltiga implementationen och har befogenhet att blockera lansering.

En mjuk checklista är inte en checklista eftersom “mestadels klart” inte har någon stabil innebörd. Under deadline blir valfria formuleringar ett minnesstöd och svåra kontroller försvinner. Namnge lanseringsmyndigheten innan QA startar. QA-ägaren kan godkänna eller underkänna; endast den namngivna innehållschefen, SEO-ansvarige eller motsvarande kan godkänna ett skriftligt undantag eller förklara en punkt icke tillämplig. De kan inte avstå från ett falskt påstående, saknat obligatoriskt element, platshållartillgång, trasig kanonisk länk eller blockerad indexerbarhet för att möta ett datum.

Varför denna grind finns, och varför den körs här

Denna grind förbrukar den godkända specifikationen för inläggstyp, elementkontrakt, källpost, slutgiltig text, implementerad kandidat och specialistgodkännanden. Den körs efter att dessa indata har frysts eftersom QA inte kan verifiera ett rörligt mål, och före publicering eftersom en defekt kan kopieras så snart webbadressen är live.

Tidigare QA certifierar ett utkast som kan ändras. Att hoppa över det gör att senare granskare inte kan skilja mellan sidförändring, ändrad specifikation och en sida som aldrig kontrollerats. QA efter publicering omvandlar billiga korrigeringar till publika defekter.

Indata och utdata

Resultatet är ett kontrakt, inte ett chattmeddelande. Utgivaren måste kunna agera på det utan att rekonstruera granskningen.

Checklistan

Varje punkt nedan inkluderar åtgärd, anledning, metod, verktyg och observerbart “klart när”-villkor. “SEO-kontrollerat” eller “ser bra ut” är aldrig godtagbara bevis.

1. Överensstämmelse med inläggstyp

Bekräfta vald inläggstyp och omfattning. Vad: matcha kandidaten mot en post i biblioteket för inläggstyper och ta bort material som tillhör en systertyp. Varför: sidtyp avgör avsikt, struktur, bevis och konverteringsbeteende. Hur: märk varje sektion med det läsarbeslut den stöder och jämför med typens syfte och undantag. Verktyg: godkänd brief, ämneskarta och sidor för inläggstyper. Klart när: exakt en primär typ är registrerad, inledningen, brödtexten och CTA:n tjänar den, och noll sektioner finns enbart för en annan typs uppgift.

Spåra obligatorisk struktur och ordintervall. Vad: kartlägg varje obligatorisk sektion till den renderade kandidaten och räkna dess ord mot det angivna intervallet. Varför: saknade sektioner skapar obesvarade frågor, medan okontrollerad längd döljer luckor bakom volym. Hur: använd en krav-till-rubrik-matris och automatiserade räkningar, inspektera sedan gränsfall manuellt. Verktyg: specifikation för inläggstyp, källa och renderad sida. Klart när: noll obligatoriska sektioner saknas och varje sektion ligger inom sitt angivna minimum och maximum.

2. Elementöverensstämmelse

Verifiera element, positioner och parametrar. Vad: jämför elementkartan med källa och rendering. Varför: position och fält är en del av funktionen; ett begravt direkt svar svarar inte längre först, och felaktiga parametrar kan bryta utdata. Hur: inspektera uppifrån och ner och validera tillåtna fält, värden, nästling och syntax. Verktyg: elementspecifikationer, validator och webbläsare. Klart när: varje obligatoriskt element är på sin obligatoriska position, varje parameter är giltig och inga oförklarade dubbletter finns kvar.

Tillämpa företräde för typade element. Vad: tillämpa reglerna för elementskrivning därhelst ett avsnitt har ett registrerat syfte. Varför: fritext kan se likadan ut men kan inte bära komponentens identitet, fält, tillgänglighetsbeteende eller strukturerade utdata. Hur: ange varje blocks uppgift som ett verb—definiera, varna, jämför, instruera, sammanfatta—och kontrollera om ett matchande element finns. Verktyg: elementbibliotek och källinspektör. Klart när: noll avsnitt använder fritext där ett typat element är obligatoriskt.

3. Innehållskvalitet

Testa svaret isolerat. Vad: läs det direkta svarsblocket utan dess rubrik eller omgivande stycken. Varför: sök- och AI-hämtningssystem kan extrahera endast den passagen. Hur: kontrollera att det namnger ämnet, svarar på frågan, innehåller nödvändig kvalificering och inte förlitar sig på “detta”, “den” eller “som ovan”. Verktyg: isolerad textvy och mänsklig granskare. Klart när: svaret är självständigt, korrekt och inom sitt angivna intervall på 40–60 ord när det elementet krävs.

Verifiera påståenden, språk och unicitet. Vad: spåra materiella påståenden till bevis, förklara fackjargong vid första användning och jämför kandidaten med sidor som tjänar samma avsikt. Varför: ogrundade påståenden skadar förtroendet, medan nära-dubbletter konkurrerar och driver. Hur: flagga namn, datum, siffror, orsakspåståenden, produktbeteende och likhetskandidater; stöd, kvalificera, konsolidera eller ta bort dem. Verktyg: bevisregister, primärkällor, webbplatssökning och likhetsrapport. Klart när: noll materiella påståenden saknar stöd, noll facktermer förblir oförklarade och ingen befintlig sida besvarar samma avsikt och omfattning utan en konsolideringsplan.

4. Frontmatter

Validera identitets- och förhandsvisningsfält. Vad: tillämpa frontmatter-specifikationen på titel, beskrivning, nyckelord, entity och kopplingar för inläggstyp. Varför: dessa fält styr routing, förhandsvisningar, scheman och relationer utan att läsa brödtexten. Hur: kör fält- och längdvalidering, jämför sedan innebörd med den synliga sidan. Verktyg: frontmatter-linter och mänsklig förhandsvisning. Klart när: titeln är unik och korrekt, beskrivningen är 150–160 tecken, nyckelorden innehåller 6–8 relevanta poster och entity matchar kontraktet för inläggstyp.

Verifiera styrnings- och FAQ-fält. Vad: kontrollera datum, författare, granskare, ägarskap och synlig FAQ-struktur mot frontmatter. Varför: anonyma poster förhindrar ansvarsskyldighet, medan FAQ-drift gör att synliga och strukturerade svar blir oense. Hur: jämför fält med lanseringsspåret och normaliserad synlig text. Verktyg: källtolk, spårare och renderad sida. Klart när: obligatoriska datum och ägare är giltiga, den mänskliga granskaren är namngiven där så krävs, FAQ-antal uppfyller typens minimum, varje par matchar och inga dolda eller tomma poster finns kvar.

5. Strukturerad data

Kräv korrekt schema. Vad: bekräfta att tillämplig schema-markup finns för sidan och dess synliga element. Varför: saknad eller generisk markup slänger bort maskinläsbar betydelse som innehållsmodellen redan tillhandahåller. Hur: jämför emitterade typer och egenskaper med kontrakten för inläggstyp och element. Verktyg: renderad HTML och schema-validator. Klart när: varje obligatorisk schematyp finns en gång, obligatoriska egenskaper är ifyllda och ingen icke tillämplig typ emitteras.

Validera paritet, inte bara syntax. Vad: jämför schemanamn, datum, författare, entitet, FAQ, steg och påståenden med synligt innehåll. Varför: giltig syntax kan fortfarande beskriva osynlig eller motsägelsefull information. Hur: validera JSON-LD, jämför sedan värden med sidan. Verktyg: strukturerad-data-test och mänsklig granskning. Klart när: det finns noll fel och noll fakta i schemat som motsäger eller överskrider synligt innehåll.

6. Intern länkning

Länka uppåt och utåt. Vad: tillhandahåll en väg till relevant pelare och kontextuella vägar till relaterade noder. Varför: hierarki hjälper läsare och crawlers att förstå var sidan hör hemma, medan laterala länkar fortsätter läsarens uppgift. Hur: kartlägg varje intern länk till en genuin nästa fråga istället för att fylla en kvot. Verktyg: länkgraf och renderad sida. Klart när: sidan har minst en länk till sin pelare, minst en relevant lateral länk där en relaterad nod finns, och minst en befintlig sida länkar in till den före eller vid publicering så att den inte blir föräldralös.

Inspektera destinationer och ankare. Vad: öppna varje destination och granska dess ankartext . Varför: en trolig webbadress kan vara saknad, omdirigerad eller orelaterad, och generiska etiketter döljer destinationens syfte. Hur: kör en internlänkskontroll, inspektera sedan ankare manuellt i meningskontext. Verktyg: crawler och webbläsare. Klart när: noll interna länkar returnerar ett fel, varje destination stöder det omgivande påståendet och inga fristående “klicka här”, råa webbadresser eller vilseledande exakta-matchning-ankare finns kvar.

7. Media

Verifiera tillgångar, alternativ och aktualitet. Vad: bekräfta att varje bild finns, har meningsfull alt-text eller ett motiverat tomt alternativ, och återspeglar det aktuella gränssnittet. Varför: trasiga, vaga, platshållar- eller inaktuella medier tar bort information och kan göra instruktioner oanvändbara. Hur: inaktivera bilder, inspektera sökvägar, återskapa produktsteg och jämför etiketter, värden, beskärning och redigering. Verktyg: tillgångskontroll, tillgänglighetsgranskning, live-produkt och webbläsare. Klart när: noll tillgångar saknas eller är platshållare, alternativ är korrekta och varje skärmbild representerar det aktuella steget.

8. Teknisk lansering

Verifiera routing, indexerbarhet och ersättning. Vad: kontrollera slug, en självhänvisande kanonisk webbadress , status, robots-beteende, indexerbarhet och omdirigeringar. Varför: innehåll kan inte prestera på fel rutt, bakom noindex eller efter att gamla webbadresser strandats. Hur: inspektera renderad head och svar, jämför registret och följ varje ersatt rutt. Verktyg: rubrikkontroll, omdirigeringskarta, källinspektör och URL-inspektion. Klart när: den godkända webbadressen returnerar 200 med en avsedd kanonisk URL och inget block; varje ersatt webbadress tar ett permanent hopp till närmaste giltiga ersättning.

Testa mobil stabilitet. Vad: inspektera läsning vid smal bredd, interaktion, överflöde och Cumulative Layout Shift . Varför: komponenter som fungerar på skrivbord kan dölja kontroller, beskära tabeller eller flytta innehåll när media laddas. Hur: testa representativa mobila bredder och ladda sidan med begränsning. Verktyg: webbläsarenhetsläge och prestandarapport. Klart när: allt innehåll och alla kontroller förblir användbara utan horisontellt sidöverflöde och uppmätt CLS är 0,1 eller lägre.

9. AI-beredskap

Testa extraktion och initial HTML. Vad: inspektera svar, definitioner, nyckelfakta, jämförelser och slutsatser som självständiga passager i serverlevererad HTML. Varför: hämtningssystem kan välja en passage och kanske inte exekverar klientsideskod. Hur: hämta initial HTML, ta bort omgivande kontext och kontrollera entitetsnamn, kvalificeringar, enheter och pronomen. Verktyg: HTML-hämtning, passagextraktor, webbläsare och AmICited-granskning. Klart när: varje prioriterat faktum finns utan JavaScript och behåller sitt ämne, sin innebörd och sina begränsningar ensamt.

Exponera procedurstruktur. Vad: verifiera att FAQ-par och ordnade steg är kodade som igenkännbara fält och förblir synliga. Varför: rubriker och formaterade rutor kan se korrekta ut medan maskiner tar emot ostrukturerad prosa. Hur: jämför elementutdata, tillgänglig struktur och schema med den synliga sekvensen. Verktyg: tillgänglighetsträd och strukturerad-data-validator. Klart när: varje obligatorisk FAQ är maskinläsbar som ett fråga-svar-par och varje obligatorisk procedur bevarar ordnade steg i synlig och strukturerad utdata.

Verktyg i AmICited

Använd produkten för att inspektera kandidaten och etablera överlämningsbevis; den ersätter inte mänskligt omdöme.

1. Öppna granskningen av agentberedskap tillsammans med AI-tillgänglighet och agentberedskap för att inspektera tillgänglighet, crawler-räckvidd, sajtkartetäckning och agentläsbart innehåll.
2. Inspektera kandidatens webbadress med URL-inspektion för att verifiera indexstatus, mobilanvändbarhet och utslag för rika resultat. Tilldela live-inspektion i överlämningen för en ny webbadress.
3. Öppna färskhetsgranskningen med Innehållsfärskhet för att ge tidskänsliga sidor en underhållssignal och nästa granskningsdatum. Historik börjar när spårning påbörjas; ingen historik betyder inte ingen förändring.
4. Använd SEO MCP via arbetsytans anslutning för repeterbara skrivskyddade URL-, färskhets-, Web Vitals- och tillgänglighetskontroller. Spara utdata eller körningsidentifierare.

Automatisering: skripta de deterministiska kontrollerna, bevara mänskliga beslut

En kontroll som kan skriptas men förblir manuell kommer att hoppas över under press. Automatisera stabila, maskinobserverbara resultat; kräv en människa för syfte, sanning och kontext.

Automatisering skriver bevis, inte godkännande. Misslyckande blockerar grinden; ett godkänt skript godkänner inte de mänskliga kolumnerna.

Beslutsregler

“Dåligt” måste vara observerbart. Använd dessa tröskelvärden om inte den valda inläggstypen eller elementet definierar ett strängare; det mer specifika kontraktet vinner.

Ej tillämpligt är inte ett mjukare godkännande. Det är giltigt endast när punkten verkligen inte är tillämplig—till exempel ingen omdirigering behövs eftersom ingen webbadress ersätts—och posten anger varför. Ett undantag måste namnge den ändrade regeln, affärsskäl, risk, godkännare, korrigeringsägare och utgångsdatum. Lanseringsmyndigheten skriver under; QA-granskaren godkänner inte sig själv.

Leverans: godkännandeposten

Bifoga en oföränderlig post till den exakta kandidaten. En senare granskning måste kunna skilja mellan “aldrig kontrollerad” och “kontrollerad och godkänd enligt specifikationsversion 1.” Lagra strukturerade fält snarare än en skärmbild av gröna bockar.

Sidsökväg / kanonisk:
Lanseringskandidat-ID eller innehållshash:
Inläggstyp och entitet:
Specifikationsversion:
QA-ägare:
Lanseringsmyndighet:
Startad / slutförd (tidsstämpel):

Kontroller:
- Grupp / punkt:
- Resultat: GODKÄNT | UNDERKÄNT | EJ TILLÄMPLIGT
- Bevis: validatorutdata, källplats, destination eller observation
- Kontrollerad av / kl:

Undantag:
- Regel och omfattning:
- Orsak och risk:
- Godkännare:
- Korrigeringsägare / utgångsdatum:

Beslut: GODKÄNT — PUBLICERA | UNDERKÄNT — HÅLL KVAR
Ägare för live-verifiering och deadline:
Nästa underhållsgranskningsdatum:

En godkännandepost är endast tillägg. En ändrad specifikation eller kandidat får en ny granskning, inte omskriven historik.

Vad som händer vid underkännande

Underkännande startar en korrigeringsloop, inte en förhandling i granskningstråden.

1. QA-ägaren markerar kandidaten som UNDERKÄNT — HÅLL KVAR, registrerar bevis och stannar vid den punkt där fortsättning skulle testa en version som säkert kommer att ändras.
2. Innehållsägaren åtgärdar fel i inläggstyp, element, text, metadata och bevis. Implementeringsägaren åtgärdar fel i schema, länkar, media, routing, rendering och automatisering. En specialist kontrollerar om påståenden inom sitt område.
3. Korrigeraren identifierar varje ändrad yta. QA-ägaren kör om den misslyckade punkten, dess beroende punkter och varje grupp som påverkas av ändringen. Ett omskrivet svar öppnar till exempel på nytt påståenden, elementöverensstämmelse, schemaparitet och AI-extraktion.
4. QA-ägaren skapar ett nytt tidsstämplat resultat. Publicering förblir blockerad tills varje tillämplig punkt är godkänd och varje EJ TILLÄMPLIGT eller undantag har giltig auktoritet.

Författaren certifierar inte sin egen korrigering. QA äger posten, produktion äger korrigeringar, specialister äger domängodkännanden och lanseringsmyndigheten äger undantag.

Vad som går fel

• Att behandla grinden som korrekturläsning. Grammatik kan vara felfri medan sidan använder fel inläggstyp, motsäger sitt schema eller inte kan indexeras.
• Att testa källa istället för lanseringskandidaten. Giltig Markdown bevisar inte att mallar emitterade den avsedda kanoniska webbadressen, tillgängliga strukturen eller responsiva layouten.
• Att göra varje punkt manuell. Granskare klickar upprepade gånger deterministiska kontroller tills en deadline lär dem att hoppa över listan.
• Att göra varje punkt automatiserad. En grön validator kan inte avgöra om bevis stöder ett orsakspåstående eller om en jämförelse svarar på läsarens beslut.
• Att acceptera “fixar efter lansering.” Det omvandlar en grind före publicering till en odokumenterad backlog och raderar innebörden av GODKÄNT.
• Att låta samma person implementera och godkänna. Självgranskning missar antaganden eftersom granskaren minns avsett beteende snarare än att observera faktisk utdata.

Överlämning

Nästa tillstånd är publicering och live-verifiering. QA överlämnar den godkända kandidaten, GODKÄNT-posten, kanonisk rutt, omdirigeringskarta, lanseringsfönster och godkända undantag. Utgivaren returnerar live-webbadressen och distributionstiden; live-verifieringsägaren upprepar kontroller av status, kanonisk URL, indexerbarhet, omdirigeringar, schema, länkar, media, mobil och CTA.

Om produktionen skiljer sig återöppnas berörda kontroller. Om den matchar, lägg till live-webbadressen och bevisen utan att skriva över kandidatens resultat. Senare granskningar använder den lagrade specifikationsversionen för att skilja drift från en ändrad standard.

FAQ

Vanliga frågor

Godkänt innebär att kandidaten överensstämmer med det aktuella kontraktet med granskningsbara bevis. Allt annat är kvarhållande. Akademiens layouts avslutande CTA följer denna FAQ.