Sidoptimerering

Sidoptimering är den sidnivåanpassning av titlar, beskrivningar, rubriker, entiteter, interna ankare och media till en enda användbar läsaruppgift. Posttypen bestämmer redan sidans strukturella uppgift; den här fasen gör att varje synlig och maskinläsbar signal beskriver den uppgiften konsekvent.

Fas: P11 · Steg C — Producera. Tidsram: 60–90 minuter för en ny sida efter redaktionellt godkännande; två till fyra timmar för en befintlig sida eftersom diagnos, bevarande och före- och efterbevis krävs. Ansvarig ägare: SEO-innehållsansvarig. Bidragsgivare: skribent eller redaktör, SEO-strateg, designer för materialmediaändringar och utvecklare när mallar genererar fel HTML.

Varför denna fas, och varför här

P11 förbrukar det godkända utkastet och produktionskontrollerna från innehållsproduktionssystemet , plus sidans intention, kanoniska webbadress, primära entiteter, nödvändiga bevis och posttypspecifikation . Strukturen har redan avgjort om tillgången är en guide, jämförelse, produktsida, ordlisteterm eller ett annat format. Sidoptimeringsarbete bör inte göra om det beslutet genom att trycka in varje sökordsvariant på sidan.

Fasen finns för att samma korrekta artikel kan skicka motstridiga signaler. En webbläsarflik kan lova “Guide till CRM-migrering för företag”, H1 kan säga “Flytta din data”, introduktionen kanske aldrig nämner vilka system som är inblandade och interna länkar kan kalla sidan “läs mer”. En människa kan härleda sambandet efter att ha läst. En sökmotor, skärmläsare eller AI-hämtningssystem måste jämka flera svagare etiketter innan det kan avgöra vad sidan handlar om och när den är användbar.

Ordningen spelar roll. Kör sidoptimering före den dedikerade internlänkningsfasen eftersom P12 behöver den slutliga webbadressen, stabila rubriker och godkända ankarkoncept. Kör den efter utkastet eftersom en titel som skrivits innan svaret finns ofta lovar en omfattning som brödtexten inte levererar. Att hoppa över P11 lämnar användbart innehåll svårare att klassificera och mindre lockande att klicka på. Att köra den under research uppmuntrar sökordsstyrd text innan sökintention —uppgiften en sökare försöker slutföra—har fastställts.

Inputs och outputs

Outputs är kontraktet med internlänkning och kvalitetssäkring före publicering. En redaktör bör inte behöva gissa vad titeln menade eller vilken rubrik som säkert kan ta emot en djup länk.

Checklistan

Checklistan skiljer sig vid första steget för en befintlig sida jämfört med en ny sida. De återstående kontrollerna delar godkännandestandarder, men bevis får aldrig kasseras enbart för att få en gammal sida att likna en ny mall.

1. Välj vägen för befintlig sida eller ny sida

Vad: Klassificera arbetet som optimering av befintlig sida eller färdigställande av ny sida innan du ändrar text. En befintlig sida har mätbar historik och kan redan tillfredsställa frågor utanför den aktuella briefen; en ny sida har ingen prestationsbaslinje att skydda.

Varför: Att redigera en levande prestationssida utan att fånga dess fungerande täckning gör förluster omöjliga att diagnostisera. Att behandla en ny sida som en nedåtgående sida inbjuder till påhittade baslinjer och för tidiga framgångsanspråk.

Hur: För en befintlig sida, exportera nuvarande titel, beskrivning, H1–H3-disposition, interna ankare, media, toppfrågor, klick, visningar, CTR, genomsnittlig position och konverteringar för ett angivet intervall. Kommentera vad som måste bevaras. För en ny sida, verifiera den godkända intentionen, posttypen, webbadressen, entitetslistan och konverteringsåtgärden; markera prestationsfälten “baslinje efter lansering”, inte noll.

Verktyg: Använd Google Search Queries på app.amicited.com/reports/google-search/queries för levande frågebevis. Använd CMS-förhandsvisningen och den godkända briefen för en ny sida.

Klart när: Ändringsprotokollet anger vägen, bevisfönstret, ägaren, skyddade frågor eller sektioner samt anledningen till arbetet. Inga textändringar på befintlig sida påbörjas utan en fångad baslinje, och ingen ny sida bedöms mot påhittad historisk prestation.

2. Bekräfta sidans enda primära löfte

Vad: Skriv en mening: “Den här sidan hjälper [målgrupp] att slutföra [uppgift] genom att tillhandahålla [svar eller beslutsstöd].” Markera ett primärt frågetema och de viktiga sekundära frågor som brödtexten verkligen besvarar.

Varför: Titlar, rubriker, entiteter, ankare och media kan bara överensstämma när sidan har en dominerande uppgift. En lista med sökord är inte ett löfte eftersom den inte säger något om resultatet läsaren får.

Hur: Jämför den godkända intentionen med det inledande svaret, bevis, resultatsidans förväntningar och uppmaningen till handling. Om utkastet tjänar två olika uppgifter med olika bevis eller nästa steg, återför det till omfattningsgranskning istället för att dölja konflikten under en bred titel.

Verktyg: Använd briefen, granskning av levande resultat och frågebevisen som bifogades i steg 1.

Klart när: En granskare kan läsa löftet och peka på det direkta svaret, stödjande sektioner och nästa åtgärd som uppfyller det. Varje kvarhållet frågetema passar samma uppgift.

3. Skriv en titel som kan överleva omskrivning

Vad: Slutför HTML-titel-taggen —sidans namn som visas i en webbläsarflik och vanligtvis används som sökresultatrubrik—och dess synliga H1.

Varför: Sökmotorer kan skriva om titlar när de är repetitiva, vaga, överfyllda, inaktuella eller inkonsekventa med den synliga sidan. Ingen formulering kan förhindra varje omskrivning, eftersom resultat anpassas till frågor och enheter. En specifik, koncis titel som överensstämmer med H1 och svaret ger systemet mindre anledning att ersätta sidans ramverk.

Hur: Inled med ämnet och ett användbart resultat, lägg till en differentierare endast när brödtexten bevisar den, och placera varumärket sist när det hjälper identifiering. Ta bort standardtext som delas över hundratals sidor. Håll H1 naturlig och något mer läsbar än titeln om det behövs, men låt båda beskriva samma omfattning. Förhandsgranska bredd istället för att behandla en teckenräkning som en rankingregel.

Verktyg: Använd CMS sökförhandsvisning, jämförelse av levande resultat och Google Search Queries för språket människor faktiskt använder.

Klart när: Den renderade källkoden innehåller en unik, icke-tom titel och en H1; ingen av dem är en lista med sökordsvarianter; deras löften överensstämmer med varandra och med det inledande svaret; och titelns viktiga ord förblir begripliga om dess slut trunkeras.

4. Skriv en beskrivning som förtjänar rätt klick

Vad: Skriv metabeskrivningen , en HTML-sammanfattning som sökmotorer kan visa under resultattiteln.

Varför: Beskrivningen är inte en garanterad snippet och är inte en plats att tvinga fram rankingar. Dess uppgift är att göra sidans värde och kvalifikation tydlig så att rätt sökare kan välja den. Sökmotorer väljer ofta synlig sidtext när den texten besvarar en fråga mer exakt.

Hur: Ange ämne, resultat, användbar begränsning och nästa steg i klarspråk. Använd den primära termen där det är naturligt. Sikta på 120–160 tecken som ett redaktionellt intervall, förhandsgranska sedan på desktop och mobil. Upprepa inte titeln, använd inte ogrundade superlativ och lova inte verktyg, priser, mallar eller bevis som saknas på sidan.

Verktyg: Använd CMS-förhandsvisningen och CTR Gap på app.amicited.com/reports/ctr-gap för befintliga resultat som får färre klick än webbplatsens förväntade värde.

Klart när: Beskrivningen är unik, korrekt utan sammanhang, läsbar i förhandsvisningen och stöds av sidan. För en befintlig CTR-gap-redigering är den tidigare beskrivningen, diagnostiserade orsaken, ersättningen och granskningsdatumet dokumenterade.

5. Gör rubriker till sidans disposition

Vad: Gör H1, H2:or och H3:or till en nästlad disposition av svaret. Rubriknivåer är semantiska HTML-etiketter, inte kontroller för teckenstorlek.

Varför: Läsare skannar rubriker för att bestämma var de ska lägga sin uppmärksamhet. Hjälpmedelsteknik använder dem för navigering, medan sök- och hämtningssystem använder dem för att associera passager med frågor och entiteter. Dekorativa eller tomma rubriker förstör den dispositionen.

Hur: Använd en H1 för sidan. Ge varje huvudsektion en H2 och reservera H3 för en verklig underavdelning av dess förälder. Skriv om vaga etiketter som “Översikt”, “Mer” och “Fördelar” så att de namnger ämnet i sitt sammanhang. Flytta stilbehov till designsystemet; välj inte H4 för att den ser mindre ut. Varje rubrik måste introducera text, en tabell, en lista, media eller något annat substantiellt svar.

Verktyg: Använd den renderade DOM-dispositionen, inte bara den visuella editorn. Kontrollera både desktop- och mobilförhandsvisningar.

Klart när: Det finns exakt en H1; ingen nivå hoppas över enbart för utseendets skull; varje H3 tillhör föregående H2; ingen rubrik är tom eller dubblerad utan en tydlig upprepad struktur; och att läsa enbart rubrikerna ger en sanningsenlig sammanfattning av sidan.

6. Namnge entiteter och ange deras relationer

Vad: Verifiera sidans entiteter—distinkta personer, organisationer, produkter, platser, standarder, metoder eller mått—och relationerna som hävdas mellan dem.

Varför: Att upprepa ett sökord avgör inte om “Mercury” betyder en planet, ett grundämne, ett bilmärke eller ett betalningsföretag. Tydliga namn, kategorier, attribut och relationer hjälper en läsare och en maskin att koppla påståenden till rätt sak.

Hur: Använd det föredragna fullständiga namnet vid första omnämnande, definiera facktermer och ange viktiga relationer i fullständiga meningar. Lägg till versioner, platser, datum, enheter och författarskap där de förändrar betydelsen. Använd synonymer naturligt efter disambiguering. Ta bort entitetslistor som inte har någon förklarande relation och verifiera varje faktamässig association mot det godkända källmaterialet.

Verktyg: Använd entitetslistan från briefen, redaktionell källlogg och sökning på renderad sida. AmICiteds frågebevis kan visa vilket ordförråd användare använder, men det verifierar inte faktamässiga relationer.

Klart när: Varje primär entitet är entydig vid första meningsfulla omnämnande, varje materiell relation har bevis, namn och versioner är konsekventa, och en redaktör kan extrahera en entitets–relationslista utan att gissa vad ett pronomen eller en akronym syftar på.

7. Få interna ankare att beskriva nästa användbara steg

Vad: Granska ankartexten —de synliga klickbara orden—för varje intern länk som redan är tilldelad sidan.

Varför: “Klicka här” och “läs mer” döljer destinationen för personer som skannar sidan och för system som tolkar relationen. Exakt-matchande upprepning är inte botemedlet; ankare bör beskriva varför destinationen hjälper vid den punkten i svaret.

Hur: Placera länkar där destinationen besvarar en fråga, tillhandahåller bevis eller möjliggör nästa uppgift. Använd koncis beskrivande språk som passar meningen. Variera formulering när sammanhanget ändras, undvik att länka samma destination upprepade gånger inom ett kort avsnitt, och lägg aldrig till en länk enbart för att placera en målfras.

Verktyg: Använd de godkända länkåtagandena, CMS-länkinspektören och den renderade sidan. Nästa fas kommer att utvärdera grafens täckning och möjligheter på källsidan.

Klart när: Varje intern länk går till den avsedda kanoniska webbadressen, noll generiska “klicka här” eller nakna URL-ankare återstår, destinationen är begriplig från sin mening, och överlämningen listar de stabila rubriker och koncept som P12 kan använda för inkommande länkar.

8. Optimera media för betydelse, tillgänglighet och hastighet

Vad: Granska bilder, diagram, tabeller, videor och inbäddningar för syfte, placering, dimensioner, filformat, bildtexter och alt-text —det textuella alternativ som presenteras när en bild inte kan ses.

Varför: Media bör förklara något som prosa inte kan visa lika effektivt. Omärkta diagram döljer bevis, saknade dimensioner orsakar layoutförskjutningar och dekorativa filer med utförlig alternativ text skapar brus för skärmläsaranvändare. Stora tillgångar kan göra svaret långsammare utan att göra det tydligare.

Hur: Behåll varje tillgång endast när den bevisar, förklarar eller demonstrerar en poäng. Skriv koncis alt-text för meningsfulla bilder baserat på deras funktion i kontext; använd tom alt-text för rent dekorativa bilder. Sätt trender och slutsatser från diagram i synlig prosa, ange bredd och höjd, använd ett effektivt format och lazy-ladda media som ligger under folden där implementationen stöder det. Ta produktskärmbilder i ett läsbart visningsfönster och redigera bort personlig eller kunddata.

Verktyg: Använd mediaförteckningen, webbläsarens tillgänglighetsinspektion, bildimensionskontroll och webbplatsens överenskomna prestandabudget.

Klart när: Varje mediaobjekt har en ägare och ett syfte; informativa tillgångar har lämplig alternativ text; dekorativa tillgångar använder tomma alternativ; diagram anger sin slutsats i text; dimensioner är deklarerade; ingen känslig data är synlig; och varje fil klarar webbplatsens mediebudget eller har ett godkänt undantag.

9. Rendera, jämför och godkänn den kompletta sidan

Vad: Granska den renderade sidan som ett system och dokumentera ändringsuppsättningen.

Varför: Fält som klarar sig var för sig kan hamna i konflikt tillsammans. En koncis titel kan begränsa omfattningen medan en gammal H2 vidgar den; en stark beskrivning kan lova en mall som tagits bort i redigeringen; ett nytt rubrik-ID kan bryta en inkommande djup länk.

Hur: Jämför titel, beskrivning, H1, inledande svar, disposition, entiteter, ankare, media och CTA mot det primära löftet. Inspektera HTML-utdata, desktop, mobil, tangentbordsnavigering och den levande destinationen för varje länk. För en befintlig sida, separera ändringar per hypotes så att senare mätning kan identifiera vad som sannolikt gav effekt.

Verktyg: Använd CMS-förhandsvisningen, webbläsarinspektorn, länkkontrollen som är tillgänglig för publiceringsteamet och AmICiteds baslinjefångster.

Klart när: Godkännandegaterna nedan alla passeras, den ansvariga ägaren godkänner den renderade webbadressen, före- och efterbevis är bifogade, publicerings- och mätdatumen är satta, och olösta problem har en ägare istället för att försvinna in i en kommentar.

Verktyg i AmICited

AmICited identifierar sidor värda att ändra och tillhandahåller bevis för ändringen. Det ersätter inte granskning av det levande resultatet, renderad HTML eller sidans löfte.

Beslutsregler

Dessa siffror är granskningsgater, inte universella algoritmtrösklar. Ett dokumenterat undantag kan passera; ett osynligt undantag kan inte.

Använd inte sökordstäthet som en gate. Täthet är ett förhållande mellan frasförekomster och totalt antal ord, men det kan inte avgöra om en sida besvarar frågan, skiljer mellan entiteter eller läses naturligt. Noll påtvingade insättningar är standarden. Likaså misslyckas en exakt-matchande rubrik utan innehåll bakom sig även om ett verktyg markerar frasen som “optimerad”.

Leverans: sidoptimeringsbladet

Överlämna en versionshanterad rad per webbadress, länkad till den CMS-klara texten och bevismappen.

URL | Väg: befintlig/ny | Primärt löfte | Målgrupp | Posttyp
Titel före | Titel efter | Beskrivning före | Beskrivning efter | H1
Rubrikdisposition | Primära entiteter | Interna ankare | Mediaförteckning
Skyddade frågor/sektioner | AmICited bevislänkar | Ändringshypotes
Ägare | Granskare | Publiceringsdatum | Mätdatum | Status | Undantag

För befintliga sidor, inkludera före- och efterbevis samt exporterade frågebevis. För nya sidor, inkludera den godkända briefen och markera prestationsfälten “väntar på baslinje”. Dokumentera varje undantag bredvid dess misslyckade gate. Publicering måste kunna implementera bladet utan att skriva om fält, och mätning måste kunna rekonstruera ändringen.

Vad går fel

• Ett poäng ersätter omdöme. Ett plugin blir grönt eftersom en fras förekommer tillräckligt ofta, medan sidan besvarar fel uppgift. Återgå till det primära löftet och observerad frågeintention.
• Snippet överlovar. En sökordsfylld titel eller ett ogrundat löfte som “gratis mall” lockar fel klick och inbjuder till omskrivning. Behåll ett ämne, ett resultat och endast påståenden som brödtexten uppfyller.
• Rubriker är dekoration. Redaktörer väljer rubriknivåer efter storlek, eller lägger till frågerubriker följda av en tom mening. Reparera dispositionen i HTML och använd designstilar för utseende.
• Exakt-matchande ankare förökas. Varje länk till en kommersiell sida använder samma styltiga fras. Skriv ankare för den lokala meningen och användarbehovet; konsekvens i destination kräver inte identisk formulering.
• En befintlig vinnare skrivs om som en tom sida. Användbara underämnen och språk försvinner eftersom den nya briefen bara dokumenterar den primära frågan. Bevara angränsande täckning och logga medvetna borttagningar.
• Varje låg CTR blir ett textproblem. En AI-översikt, bildpaket, varumärkesmismatch eller fel målsida kan undertrycka klick. Inspektera det levande resultatet innan du ändrar snippet.
• Sökmotorers omskrivningar utlöser dagliga redigeringar. En observerad titelvariation orsakar reaktiva ändringar som raderar experimentet. Samla upprepade, frågespecifika bevis och ändra endast när sidan i sig är felriktad.

Nästa fas

Internlänkningsfasen tar emot den slutliga kanoniska webbadressen, det primära löftet, en stabil rubrikdisposition, godkända entiteter, befintliga utgående länkar och kandidatankarkoncept. Den använder dessa fält för att avgöra vilka relevanta sidor som ska länka in, vilka kontextuella vägar som ska leda ut, och hur sidan passar webbplatsens bredare graf.

Överlämna inte en preliminär rubrikkarta eller en webbadress som kan ändras efter publicering. P12 bör besluta om länkplacering och täckning, inte ompröva sidans intention eller uppfinna etiketter för ett ofärdigt svar. Sidans ägare förblir ansvarig för eventuella formuleringar som behövs för att göra en planerad länk naturlig.

Få sidnivåsignalerna att stämma överens

Börja med sidans faktiska bevis: öppna frågerapporten för den ägande webbadressen, använd CTR-möjlighetsrapporten när klick underpresterar den förväntade nivån, eller öppna sidmöjlighetsarbetslistan när ett kluster är tillräckligt nära för att förbättras. Skicka sedan en dokumenterad sidnivåhypotes, inte ett knippe sökordsinsättningar.