On-Page-optimalisering

On-page-optimalisering er justering på sidenivå av titler, beskrivelser, overskrifter, enheter, interne ankertekster og media mot én nyttig leseroppgave. Posttypen bestemmer allerede sidens strukturelle jobb; denne fasen får hvert synlige og maskinlesbare signal til å beskrive den jobben konsekvent.

Fase: P11 · Trinn C — Produser. Tidsramme: 60–90 minutter for en ny side etter redaksjonell godkjenning; to til fire timer for en eksisterende side fordi diagnose, bevaring og før-og-etter-dokumentasjon kreves. Ansvarlig eier: SEO-innholdsansvarlig. Bidragsytere: skribent eller redaktør, SEO-strateg, designer for vesentlige medieendringer, og utvikler når maler produserer feil HTML.

Hvorfor denne fasen, og hvorfor her

P11 tar imot det godkjente utkastet og produksjonskontrollene fra innholdsproduksjonssystemet , samt sidens intensjon, kanoniske URL, primære enheter, nødvendig dokumentasjon og posttype-spesifikasjon . Strukturen har allerede avgjort om eiendelen er en guide, sammenligning, produktside, ordliste-term eller et annet format. On-page-arbeid bør ikke omgjøre den beslutningen ved å presse alle søkevarianter inn på siden.

Fasen eksisterer fordi den samme korrekte artikkelen kan sende motstridende signaler. En nettleserfane kan love «Enterprise CRM-migreringsguide», H1-en kan si «Flytte dataene dine», introduksjonen kan aldri nevne systemene som er involvert, og interne lenker kan kalle siden «les mer». Et menneske kan utlede sammenhengen etter å ha lest. En søkemotor, skjermleser eller AI-hentingssystem må forene flere svakere etiketter før det kan avgjøre hva siden handler om og når den er nyttig.

Rekkefølgen betyr noe. Utfør on-page-optimalisering før den dedikerte interne lenkefasen fordi P12 trenger den endelige URL-en, stabile overskrifter og godkjente ankerkonsepter. Utfør den etter utkastet fordi en tittel skrevet før svaret eksisterer, ofte lover et omfang kroppen ikke leverer. Å hoppe over P11 gjør nyttig innhold vanskeligere å klassifisere og mindre fristende å klikke på. Å utføre den under research oppmuntrer til nøkkelordstyrt tekst før søkeintensjon — oppgaven en søker prøver å fullføre — er avgjort.

Inndata og utdata

Resultatene er kontrakten med intern lenking og kvalitetssikring før publisering. En redaktør bør ikke måtte gjette hva tittelen mente eller hvilken overskrift som trygt kan motta en dyp lenke.

Sjekklisten

Sjekklisten skiller seg fra første steg for en eksisterende side og en ny side. De resterende kontrollene deler godkjenningsstandarder, men dokumentasjon må aldri forkastes bare for å få en gammel side til å ligne en ny mal.

1. Velg ruten for eksisterende side eller ny side

Hva: Klassifiser arbeidet som optimalisering av eksisterende side eller fullføring av ny side før du endrer tekst. En eksisterende side har målbar historikk og kan allerede oppfylle forespørsler utenfor det gjeldende oppdraget; en ny side har ingen ytelsesreferanse å beskytte.

Hvorfor: Å redigere en side som presterer, uten å fange opp dens fungerende dekning, gjør tap umulig å diagnostisere. Å behandle en ny side som en side i nedgang inviterer til oppdiktede referanseverdier og forhastede påstander om suksess.

Hvordan: For en eksisterende side, eksporter gjeldende tittel, beskrivelse, H1–H3-disposisjon, interne ankertekster, media, toppforespørsler, klikk, visninger, CTR, gjennomsnittsposisjon og konverteringer for en angitt periode. Noter hva som må bevares. For en ny side, verifiser godkjent intensjon, posttype, URL, enhetsliste og konverteringshandling; merk ytelsesfeltene «referanseverdi etter lansering», ikke null.

Verktøy: Bruk Google Search Queries på app.amicited.com/reports/google-search/queries for levende forespørselsdokumentasjon. Bruk CMS-forhåndsvisningen og det godkjente oppdraget for en ny side.

Ferdig når: Endringsloggen angir ruten, dokumentasjonsvinduet, eier, beskyttede forespørsler eller seksjoner, og årsaken til arbeidet. Ingen tekstdringer på eksisterende side starter uten en fanget referanseverdi, og ingen ny side bedømmes ut fra oppdiktet historisk ytelse.

2. Bekreft sidens eneste primære løfte på nytt

Hva: Skriv én setning: «Denne siden hjelper [målgruppe] med å fullføre [oppgave] ved å tilby [svar eller beslutningsstøtte].» Marker ett primært forespørselstema og de viktige sekundære spørsmålene kroppen faktisk besvarer.

Hvorfor: Titler, overskrifter, enheter, ankertekster og media kan bare samsvare når siden har én dominerende jobb. En liste med nøkkelord er ikke et løfte fordi den ikke sier noe om resultatet leseren får.

Hvordan: Sammenlign den godkjente intensjonen med det innledende svaret, dokumentasjonen, forventningene til resultatsiden og handlingsoppfordringen. Hvis utkastet tjener to forskjellige oppgaver med ulik dokumentasjon eller neste steg, send det tilbake til omfangsgjennomgang heller enn å skjule konflikten innenfor en bred tittel.

Verktøy: Bruk oppdraget, gjennomgang av levende resultater og forespørselsdokumentasjonen vedlagt i steg 1.

Ferdig når: En gjennomgående leser kan lese løftet og peke på det direkte svaret, støttende seksjoner og neste handling som oppfyller det. Hvert bevart forespørselstema passer til den samme jobben.

3. Skriv en tittel som kan overleve omskriving

Hva: Ferdigstill HTML-tittel-taggen — sidenavnet som vises i en nettleserfane og vanligvis brukes som søkeresultatoverskrift — og dens synlige H1.

Hvorfor: Søkemotorer kan omskrive titler når de er repetitive, vage, stappfulle, foreldede eller inkonsistente med den synlige siden. Ingen formulering kan forhindre enhver omskriving, fordi resultater tilpasser seg forespørsler og enheter. En spesifikk, konsis tittel som samsvarer med H1 og svaret, gir systemet mindre grunn til å erstatte sidens rammeverk.

Hvordan: Led med emnet og nyttig resultat, legg til en differensiator bare når kroppen beviser det, og plasser merkevaren sist når det hjelper identifikasjon. Fjern standardtekst som deles på tvers av hundrevis av sider. Hold H1 naturlig og litt mer lesbar enn tittelen om nødvendig, men få begge til å beskrive samme omfang. Forhåndsvis bredde heller enn å behandle en tegnbegrensning som en rangeringsregel.

Verktøy: Bruk CMS-søk-forhåndsvisningen, sammenligning av levende resultater og Google Search Queries for språket folk faktisk bruker.

Ferdig når: Den renderte kilden inneholder én unik, ikke-tom tittel og én H1; ingen av dem er en liste med nøkkelordvarianter; løftene deres samsvarer med hverandre og det innledende svaret; og tittelens viktige ord forblir forståelige om halen blir avkuttet.

4. Skriv en beskrivelse som fortjener det riktige klikket

Hva: Skriv meta-beskrivelsen , et HTML-sammendrag som søkemotorer kan vise under resultattittelen.

Hvorfor: Beskrivelsen er ikke et garantert utdrag og er ikke et sted å tvinge frem rangeringer. Jobben er å tydeliggjøre sidens verdi og kvalifikasjoner så den rette søkeren kan velge den. Søkemotorer velger vanligvis synlig sidetekst når den teksten svarer mer presist på en forespørsel.

Hvordan: Oppgi emne, resultat, nyttig begrensning og neste steg i klart språk. Bruk den primære termen der det er naturlig. Sikt på 120–160 tegn som et redaksjonelt spenn, og forhåndsvis deretter på desktop og mobil. Ikke gjenta tittelen, bruk ubegrunnede superlativer, eller lov verktøy, priser, maler eller dokumentasjon som mangler på siden.

Verktøy: Bruk CMS-forhåndsvisningen og CTR Gap på app.amicited.com/reports/ctr-gap for eksisterende resultater som får færre klikk enn nettstedets forventede verdi.

Ferdig når: Beskrivelsen er unik, nøyaktig uten kontekst, lesbar i forhåndsvisningen og støttet av siden. For en eksisterende CTR-gap-redigering, er forrige beskrivelse, diagnostiserte årsak, erstatning og gjennomgåelsesdato registrert.

5. Gjør overskrifter til sidedisposisjonen

Hva: Gjør H1, H2-er og H3-er til en nestet disposisjon av svaret. Overskriftsnivåer er semantiske HTML-etiketter, ikke kontroller for skriftstørrelse.

Hvorfor: Lesere skanner overskrifter for å bestemme hvor de skal investere oppmerksomhet. Hjelpemiddelteknologi bruker dem for navigasjon, mens søke- og hentingssystemer bruker dem til å knytte avsnitt til spørsmål og enheter. Dekorative eller tomme overskrifter ødelegger den disposisjonen.

Hvordan: Bruk én H1 for siden. Gi hver hovedseksjon en H2 og reserver H3 for en reell underinndeling av dens overordnede. Skriv om vage etiketter som «Oversikt», «Mer» og «Fordeler» slik at de navngir emnet i kontekst. Flytt stilbehov til designsystemet; ikke velg H4 fordi den ser mindre ut. Hver overskrift må introdusere tekst, en tabell, en liste, media eller et annet substantivt svar.

Verktøy: Bruk den renderte DOM-disposisjonen, ikke bare den visuelle editoren. Sjekk både desktop- og mobilforhåndsvisninger.

Ferdig når: Det er nøyaktig én H1; intet nivå hoppes over bare for utseendets skyld; hver H3 tilhører den foregående H2; ingen overskrift er tom eller duplisert uten en tydelig gjentatt struktur; og det å lese bare overskriftene gir et sannferdig sammendrag av siden.

6. Navngi enheter og angi deres relasjoner

Hva: Verifiser sidens enheter — distinkte personer, organisasjoner, produkter, steder, standarder, metoder eller målinger — og relasjonene som hevdes mellom dem.

Hvorfor: Å gjenta et nøkkelord avgjør ikke om «Kvikksølv» betyr en planet, et grunnstoff, et bilmerke eller et betalingsselskap. Tydelige navn, kategorier, attributter og relasjoner hjelper en leser og en maskin med å koble påstander til rett ting.

Hvordan: Bruk det foretrukne fullstendige navnet ved første omtale, definer spesialiserte termer, og oppgi viktige relasjoner i fullstendige setninger. Legg til versjoner, steder, datoer, enheter og forfatterskap der de endrer betydning. Bruk synonymer naturlig etter avklaring. Fjern enhetslister som ikke har noen forklarende relasjon, og verifiser hver faktiske tilknytning mot det godkjente kildematerialet.

Verktøy: Bruk enhetslisten fra oppdraget, redaksjonell kildelogg og sidens renderte søk. AmICited-forespørselsdokumentasjon kan vise vokabularet brukere bruker, men den verifiserer ikke faktiske relasjoner.

Ferdig når: Hver primærenhet er entydig ved første meningsfulle omtale, hver vesentlig relasjon har dokumentasjon, navn og versjoner er konsistente, og en redaktør kan trekke ut en enhets–relasjonsliste uten å måtte gjette hva et pronomen eller akronym refererer til.

7. Få interne ankertekster til å beskrive neste nyttige steg

Hva: Gå gjennom ankerteksten — de synlige klikkbare ordene — for hver interne kobling som allerede er tildelt siden.

Hvorfor: «Klikk her» og «lær mer» skjuler destinasjonen for personer som skanner siden og for systemer som tolker relasjonen. Eksakt-match-gjentakelse er ikke løsningen; ankertekster bør beskrive hvorfor destinasjonen hjelper på det punktet i svaret.

Hvordan: Plasser lenker der destinasjonen løser et spørsmål, gir bevis, eller muliggjør neste oppgave. Bruk konsis beskrivende språk som passer i setningen. Varier ordlyd når konteksten endres, unngå å lenke til samme destinasjon gjentatte ganger innenfor én kort seksjon, og legg aldri til en lenke bare for å plassere en målfrase.

Verktøy: Bruk de godkjente lenkeforpliktelsene, CMS-lenkeinspektøren og den renderte siden. Den neste fasen vil evaluere graffdekning og kildesidemuligheter.

Ferdig når: Hver intern lenke peker til den tiltenkte kanoniske URL-en, ingen generiske «klikk her» eller bare URL-ankertekster gjenstår, destinasjonen er forståelig fra setningen sin, og overleveringen lister de stabile overskriftene og konseptene P12 kan bruke for innkommende lenker.

8. Optimaliser media for mening, tilgang og hastighet

Hva: Gå gjennom bilder, diagrammer, tabeller, video og innebygde elementer for formål, plassering, dimensjoner, filformat, bildetekster og alternativ tekst — det tekstlige alternativet som kunngjøres når et bilde ikke kan sees.

Hvorfor: Media bør forklare noe prosa ikke kan vise like effektivt. Umerkede diagrammer skjuler dokumentasjon, manglende dimensjoner forårsaker layoutendringer, og dekorative filer med detaljert alternativ tekst skaper støy for skjermleserbrukere. Store eiendeler kan gjøre svaret tregere uten å gjøre det tydeligere.

Hvordan: Behold hver eiendel bare når den beviser, forklarer eller demonstrerer et poeng. Skriv konsis alternativ tekst for meningsfulle bilder basert på deres funksjon i kontekst; bruk tom alternativ tekst for rent dekorative bilder. Sett trender og hovedpoenger fra diagrammer i synlig prosa, oppgi bredde og høyde, bruk et effektivt format, og latlast media under folden der implementeringen støtter det. Ta produkt-skjermbilder i lesbar visning og sladd personlige eller kundedata.

Verktøy: Bruk mediemanifestet, nettleser-tilgjengelighetsinspeksjon, bildedimensjonssjekk og nettstedets avtalte ytelsesbudsjett.

Ferdig når: Hvert medieelement har en eier og et formål; informative eiendeler har passende alternativ tekst; dekorative eiendeler bruker tomme alternativer; diagrammer angir hovedpoenget sitt i tekst; dimensjoner er deklarert; ingen sensitive data er synlige; og hver fil passer innenfor nettstedets mediebudsjett eller har et godkjent unntak.

9. Render, sammenlign og godkjenn den komplette siden

Hva: Gå gjennom den renderte siden som ett system og registrer endringssettet.

Hvorfor: Felt som består alene, kan komme i konflikt sammen. En konsis tittel kan begrense omfanget mens en gammel H2 utvider det; en sterk beskrivelse kan love en mal som ble fjernet i redigeringen; en ny overskrifts-ID kan bryte en innkommende dyp lenke.

Hvordan: Sammenlign tittel, beskrivelse, H1, innledende svar, disposisjon, enheter, ankertekster, media og CTA mot det primære løftet. Inspiser HTML-utdata, desktop, mobil, tastaturnavigasjon og den levende destinasjonen til hver lenke. For en eksisterende side, separer endringer etter hypotese slik at senere måling kan identifisere hva som sannsynligvis flyttet seg.

Verktøy: Bruk CMS-forhåndsvisningen, nettleserinspektøren, lenkesjekkeren tilgjengelig for publiseringsteamet, og AmICited-referanseverdiene.

Ferdig når: Godkjenningsgrensene nedenfor alle bestås, den ansvarlige eieren godkjenner den renderte URL-en, før-og-etter-dokumentasjon er vedlagt, publiserings- og måledatoene er satt, og uløste problemstillinger har en eier heller enn å forsvinne inn i en kommentar.

Verktøy i AmICited

AmICited identifiserer sider verdt å endre og leverer dokumentasjon for endringen. Den erstatter ikke gjennomgang av det levende resultatet, renderte HTML eller sideløftet.

Beslutningsregler

Disse tallene er gjennomgangsgrenser, ikke universelle algoritmeterskler. Et dokumentert unntak kan bestå; et usynlig unntak kan ikke.

Ikke bruk nøkkelordtetthet som en grense. Tetthet er et forhold mellom fraseforekomster og totalt antall ord, men det kan ikke avgjøre om en side svarer på spørsmålet, skiller enheter eller leses naturlig. Null tvungne innsettinger er standarden. Likeledes feiler en eksakt-match-overskrift uten innhold bak seg, selv om et verktøy merker frasen som «optimalisert».

Leveranse: on-page-endringsarket

Overlevere én versjonert rad per URL, koblet til den CMS-klare kopien og dokumentasjonsmappen.

URL | Rute: eksisterende/ny | Primært løfte | Målgruppe | Posttype
Tittel før | Tittel etter | Beskrivelse før | Beskrivelse etter | H1
Overskriftsdisposisjon | Primære enheter | Interne ankertekster | Mediemanifest
Beskyttede forespørsler/seksjoner | AmICited-dokumentasjonslenker | Endringshypotese
Eier | Gjennomgåer | Publiseringsdato | Måledato | Status | Unntak

For eksisterende sider, inkluder før-og-etter-bevis og eksportert forespørselsdokumentasjon. For nye sider, inkluder det godkjente oppdraget og merk ytelsesfeltene «venter på referanseverdi». Registrer hvert unntak ved siden av dets mislykkede grense. Publisering må kunne implementere arket uten å skrive om felt, og måling må kunne rekonstruere endringen.

Hva går galt

• En poengsum erstatter skjønn. Et tillegg blir grønt fordi en frase forekommer ofte nok, mens siden svarer på feil oppgave. Gå tilbake til det primære løftet og observert søkeintensjon.
• Utdraget lover for mye. En nøkkelordfylt tittel eller et ubegrunnet løfte som «gratis mal» får feil klikk og inviterer til omskriving. Hold ett emne, ett resultat og bare påstander kroppen oppfyller.
• Overskrifter er dekorasjon. Redaktører velger overskriftsnivåer for størrelse, eller legger til spørsmålsoverskrifter etterfulgt av én tom setning. Reparer disposisjonen i HTML og bruk designstiler for utseende.
• Eksakt-match-ankertekster formerer seg. Hver lenke til en kommersiell side bruker den samme vanskelige frasen. Skriv ankertekster for den lokale setningen og brukerbehovet; konsistens i destinasjon krever ikke identisk ordlyd.
• En eksisterende vinner skrives om som en blank side. Nyttige underemner og språk forsvinner fordi det nye oppdraget bare registrerer den primære forespørselen. Bevar tilstøtende dekning og logg bevisste fjerninger.
• Hver lav CTR blir et kopiproblem. Et AI-sammendrag, bildevisning, merkevaremismatch eller feil landingsside kan undertrykke klikk. Inspiser det levende resultatet før du endrer utdraget.
• Søkemotorskriving utløser daglige redigeringer. Én observert tittelvariasjon forårsaker reaktive endringer som sletter ut eksperimentet. Samle gjentatt, forespørselsspesifikk dokumentasjon og endre bare når siden i seg selv er feiljustert.

Neste fase

Den interne lenkefasen mottar den endelige kanoniske URL-en, primære løftet, stabile overskriftsdisposisjonen, godkjente enheter, eksisterende utgående lenker og kandidatankertekstkonsepter. Den bruker disse feltene til å avgjøre hvilke relevante sider som bør lenke inn, hvilke kontekstuelle ruter som bør lede ut, og hvordan siden passer inn i nettstedets bredere graf.

Ikke overlever et foreløpig overskriftskart eller en URL som kan endres etter publisering. P12 bør bestemme lenkeplassering og dekning, ikke gjenåpne sidens intensjon eller finne opp etiketter for et ufullstendig svar. On-page-eieren forblir ansvarlig for eventuelle ordlydsendringer som trengs for å få en planlagt lenke til å føles naturlig.

Få signalene på sidenivå til å samsvare

Start med sidens faktiske dokumentasjon: åpne Queries-rapporten for den eierende URL-en, bruk CTR-mulighetsrapporten når klikkene underpresterer i forhold til forventningen, eller åpne arbeidslisten for sidemuligheter når en klynge er nær nok til å forbedres. Lever så én dokumentert hypotese på sidenivå, ikke en bunke med nøkkelordinnsettinger.