Teknisk baseline-revisjon

Fase P2 · Trinn A — Forstå
Tidsramme: 2–4 timer for en lett gjennomgang, 1–2 arbeidsdager for en standard gjennomgang, eller 3–8 arbeidsdager for en dyp gjennomgang.
Eier: den tekniske SEO-lederen. Utvikling, analyse, innhold og lokalisering bidrar med bevis og godkjenner rettelser innenfor sine områder.

En teknisk baseline-revisjon fastslår om søkemotorer kan nå, tolke og velge ut URL-ene virksomheten forventer at de skal vise. Omfanget dekker gjennomsøkingskontroller, HTTP-svar, indeksering, kanoniske URL-er, lenker, rendering, internasjonal målretting og sikker levering. Resultatet er et prioritert funnregister med navngitte eiere og aksepttester, ikke en poengsum.

Hvorfor denne fasen kommer her

Å publisere på et nettsted med gjennomsøkings- eller indekseringsproblemer forsterker skaden. Søkemotorer oppdager ofte en gjentatt feil på tvers av nye URL-er raskere enn de vurderer og belønner innholdet. En ødelagt kanonisk mal kan peke hver artikkel et annet sted; en robots-regel kan skjule en katalog; klientrendert navigasjon kan skape foreldreløse sider for en ikke-JavaScript-klient. Hver nye side forstørrer det berørte settet og gjør reparasjon mer risikofylt.

Fiks grunnmuren først. Rekkefølgen er gjennomsøkbarhet → indekserbarhet → innholdskvalitet → ytelse fordi hvert lag er en port. Gjennomsøkbarhet betyr at en gjennomsøker kan oppdage og be om en URL; indekserbarhet betyr at den tilgjengelige URL-en er kvalifisert for inkludering. Først da bør innholdskvalitet og ytelse vurderes. En rask side blokkert av robots.txt kan ikke konkurrere, og tittel-tagger spiller ingen rolle på utilgjengelige sider.

Denne fasen bruker omfanget, prioriterte reiser, markeder og risikoer fra Discovery and goals . Å utføre den tidligere produserer en gjennomsøking uten forretningskontekst. Å hoppe over den lar forskning og produksjon rette seg mot maler som ikke pålitelig kan komme inn i indeksen.

Inndata og utdata

Inndata definerer det tiltenkte nettstedet, ikke bare hva en gjennomsøker finner. Utdata forteller neste eier hvilke URL-er som er trygge å teste og hvilke som fortsatt er blokkert.

Velg revisjonsdybde

Velg dybde før gjennomsøking. Estimatene forutsetter at tilgang er klar og ekskluderer implementering.

Sjekklisten

Arbeid i rekkefølge. En mislykket port kan ugyldiggjøre senere prøver, så registrer feilen og omfanget før du fortsetter.

1. Bekreft at målet er produksjon

Hva du skal gjøre: verifiser skjema, vert, robots-fil, analyseegenskap, Search Console-egenskap og sitemap-vert. Hvorfor det betyr noe: staging kan se rent ut mens produksjon fortsatt er ødelagt. Slik gjør du det: oppløs den avtalte kanoniske verten, sammenlign prioriterte sider og svarheadere, og registrer gjennomsøkingsopprinnelsen. Verktøy: nettleser, gjennomsøkerkonfigurasjon, Search Console-velger. Ferdig når: registeret navngir den bekreftede produksjonsopprinnelsen og egenskapen, uten staging-vertsnavn i seed- eller eksportfiler.

2. Test robots.txt før gjennomsøking

Hva du skal gjøre: inspiser hver produksjonsverts /robots.txt og refererte sitemaps. Hvorfor det betyr noe: en disallow-regel hindrer gjennomsøking før innhold kan vurderes. Slik gjør du det: sammenlign Disallow-mønstre med den tiltenkte beholdningen, test URL-er som matcher og ikke matcher, og skill en gjennomsøkingsblokk fra noindex. Verktøy: rått svar og robots-tester. Ferdig når: robots returnerer 200, tiltenkte blokkeringer har grunner, indekserbare prøver er tillatt, og én utilsiktet blokkering utløser et kritisk funn.

3. Avstem sitemaps med virkelige URL-er

Hva du skal gjøre: sammenlign innsendte sitemaps med den kanoniske, indekserbare beholdningen. Hvorfor det betyr noe: et sitemap bør navngi URL-er nettstedet ønsker valgt, ikke omdirigeringer, feil eller duplikater. Slik gjør du det: normaliser oppføringer, sammenlign tellinger per mal, og stikkprøv tillegg og utelatelser i Sitemaps and Indexing . Verktøy: https://app.amicited.com/reports/google-search/sitemaps-indexing og gjennomsøkingseksporter. Ferdig når: dekning er minst 95 %, 0 oppføringer omdirigerer eller gir feil, og ethvert gap har en grunn eller eier.

4. Mål statuskodefordeling

Hva du skal gjøre: klassifiser svar som 2xx, 3xx, 4xx eller 5xx. Hvorfor det betyr noe: feil stopper henting og omdirigeringer legger til hopp. Slik gjør du det: følg og rapporter omdirigeringer, segmenter etter mal, og sammenlign med Bing Crawl . Verktøy: https://app.amicited.com/reports/bing-webmasters/crawl, gjennomsøker og overvåking. Ferdig når: indekserbare URL-er returnerer 200; interne feil, løkker og kjeder er null; og bevisste omdirigeringer er dokumentert.

5. Fjern omdirigeringskjeder og løkker

Hva du skal gjøre: spor omdirigeringer til deres endelige svar. Hvorfor det betyr noe: hopp bremser oppdagelse; en løkke når aldri innhold. Slik gjør du det: eksporter stier, oppdater interne lenker til endelige kanoniske URL-er, og konsolider regler. Verktøy: omdirigeringsrapport og header-sjekker. Ferdig når: interne lenker går direkte, arve-omdirigeringer tar ett hopp, og ingen løkke eller kjede gjenstår.

6. Etabler den kvalifiserte indekseringsandelen

Hva du skal gjøre: sammenlign Googles indekstilstand med bevisst kvalifiserte URL-er. Hvorfor det betyr noe: å inkludere omdirigeringer, filtre, duplikater eller noindex-sider gjør andelen meningsløs. Slik gjør du det: bygg den kvalifiserte nevneren, inspiser prioriterte prøver i URL Inspection , og grupper ekskluderinger etter mal. Verktøy: https://app.amicited.com/reports/google-search/url-inspection, Search Console og beholdning. Ferdig når: minst 90 % er indeksert eller hvert gap har en grunnårsakeier; under 80 % er et hovedfunn.

7. Verifiser kanonisk korrekthet

Hva du skal gjøre: sammenlign erklærte, endelige og Google-valgte kanoniske URL-er. En kanonisk URL er den foretrukne versjonen blant lignende URL-er. Hvorfor det betyr noe: en feil kanonisk URL konsoliderer signaler bort fra den tiltenkte siden. Slik gjør du det: test unike sideselvreferanser, bevisste krysskanoniske URL-er, og konsistens på tvers av HTML, sitemaps, omdirigeringer og lenker. Verktøy: kanonisk rapport og https://app.amicited.com/reports/google-search/url-inspection. Ferdig når: 100 % av unike indekserbare sider navngir én absolutt, 200, indekserbar kanonisk URL, med hvert valgte avvik forklart.

8. Finn duplikat- og nærduplikatklynger

Hva du skal gjøre: grupper URL-er med identisk eller vesentlig overlappende hovedinnhold og samme søkeformål. Hvorfor det betyr noe: duplikater splitter interne signaler og tvinger søkemotorer til å velge en versjon virksomheten kanskje ikke foretrekker. Slik gjør du det: sammenlign eksakte hash-verdier, normalisert tekstlikhet, titler, kanoniske URL-er, parametere og malfunksjon; velg deretter konsolidering, differensiering, noindex eller fjerning. Verktøy: gjennomsøker-duplikatrapporter, sidebeholdning og Google Search Pages . Ferdig når: ingen klynge inneholder mer enn én uforklarlig kanonisk indekserbar URL som tjener samme hensikt, og hver aksepterte variant har et distinkt formål registrert.

9. Finn foreldreløse sider og mål lenkedybde

Hva du skal gjøre: sammenstill gjennomsøker-URL-er med sitemaps, analyse, Search Console, CMS-eksporter og tilbakelenker for å finne sider uten gjennomsøkbar intern lenke. Mål den korteste klikkstien fra hjemmesiden. Hvorfor det betyr noe: en foreldreløs side kan vises i et sitemap men likevel motta lite intern kontekst eller autoritet; overdreven dybde gjør oppdagelse skjør. Slik gjør du det: sammenlign kilder, inspiser katalogmønstre i Directory View , og spor navigasjon, brødsmuler, knutepunkter og kontekstuelle lenker. Verktøy: https://app.amicited.com/reports/directory og en flerkilde-gjennomsøking. Ferdig når: tiltenkt antall foreldreløse sider er null, prioriterte sider er innen tre klikk fra hjemmesiden, andre tiltenkte indekserbare sider er innen fem, og ethvert unntak har en bevisst oppdagelsesrute.

10. Sammenlign rendret og ikke-JavaScript HTML

Hva du skal gjøre: sammenlign det første serversvaret med siden etter at JavaScript har kjørt. Hvorfor det betyr noe: en nettleser kan vise innhold og lenker som en ikke-JavaScript-klient aldri mottar. Slik gjør du det: hent representative sider med skript deaktivert, inspiser rå HTML, sammenlign deretter overskrifter, hovedtekst, lenker, kanonisk URL, robots-direktiver, strukturerte data og status etter rendering. Verktøy: gjennomsøker i HTML- og rendringsmodus pluss nettleserens utviklerverktøy. Ferdig når: det første svaret inneholder primært innhold, kanonisk URL, indeks-direktiver og gjennomsøkbar navigasjon som trengs for å oppdage prioriterte sider; enhver JavaScript-avhengighet er eksplisitt akseptert og testet på tvers av maler.

11. Valider hreflang der det er aktuelt

Hva du skal gjøre: verifiser annotasjoner som kobler språk- eller regionale ekvivalenter. Hvorfor det betyr noe: ufullstendige eller motstridende klynger kan få søkemotorer til å ignorere målretting og vise feil markedsversjon. Slik gjør du det: test gyldige språk-regionkoder, absolutte kanoniske URL-er, selvreferanser, gjensidige returlenker, x-default der det har en reell reservasjonsrolle, og indekserbarhet for hvert mål. Verktøy: gjennomsøker-hreflangrapport og URL-prøver. Ferdig når: ugyldige koder, manglende selvreferanser, manglende returer, ikke-kanoniske mål, omdirigeringer og feil er alle null. Hvis nettstedet ikke har lokaliserte ekvivalenter, noter «ikke aktuelt» i stedet for å finne opp annotasjoner.

12. Test paginering og gjennomsøkingsstier

Hva du skal gjøre: verifiser at flersiders kategori- eller arkivsekvenser eksponerer gjennomsøkbare lenker og nyttige unike URL-er. Hvorfor det betyr noe: uendelig rulling eller knappebasert lasting kan skjule dypere elementer, mens kanonisering av hver side til side én kan fjerne distinkt beholdning fra oppdagelse. Slik gjør du det: deaktiver JavaScript, følg neste- og nummererte lenker, inspiser status, kanonisk URL og robots-direktiver, og test siste side og parameterverdier utenfor rekkevidde. Verktøy: ikke-rendret gjennomsøking og nettleser. Ferdig når: hvert tiltenkt element er tilgjengelig via ankerlenker, hver nyttig side selvkanoniserer, ugyldige sidetall returnerer en passende feil i stedet for en myk 200, og ingen sekvens skaper et ubegrenset URL-rom.

13. Sjekk mobilparitet

Hva du skal gjøre: sammenlign mobil- og desktop-levering for innhold, lenker, metadata, direktiver, strukturerte data og svarstatus. Hvorfor det betyr noe: Google vurderer hovedsakelig mobilrepresentasjonen; å skjule meningsfylt innhold eller lenker kun på mobil endrer hva det kan forstå. Slik gjør du det: gjennomsøk med desktop- og smarttelefon-brukeragenter og sammenlign representative maler, ikke bare visuelle skjermbilder. Verktøy: parede gjennomsøkinger, mobil URL-inspeksjon og nettleserens responsiv modus. Ferdig når: alt indekserbart innhold og alle gjennomsøkbare lenker som kreves for mening og oppdagelse er likeverdige, med null mobilblokkeringer, kanoniske forskjeller eller feilsvar.

14. Håndhev HTTPS og fjern blandet innhold

Hva du skal gjøre: verifiser sikker levering, vertsomdirigeringer, sertifikater, kanonisk skjema, interne URL-er og ressurser lastet over HTTP. Blandet innhold betyr at en HTTPS-side ber om en usikker ressurs. Hvorfor det betyr noe: usikre forespørsler kan blokkeres, eksponere brukere og skape inkonsistente URL-signaler. Slik gjør du det: gjennomsøk alle HTTP-varianter, inspiser sertifikatdekning og nettlesersikkerhetsfeil, og søk i rendrede ressursforespørsler. Verktøy: gjennomsøker, nettleserens sikkerhetspanel og serverkonfigurasjon. Ferdig når: hver HTTP-side omdirigerer én gang til sin tilsvarende HTTPS-URL, alle kanoniske URL-er og interne lenker bruker HTTPS, sertifikater er gyldige for hver live vert, og aktive eller passive forespørsler med blandet innhold er null.

Verktøy i AmICited

Bruk produktrapporter som sjekklistebevis, ikke som en erstatning for gjennomsøking.

• Sitemaps and Indexing på https://app.amicited.com/reports/google-search/sitemaps-indexing viser innsendt sitemap-status, advarsler, feil og indekseringshandlinger.
• URL Inspection på https://app.amicited.com/reports/google-search/url-inspection gir Googles live-vurdering for utvalgte URL-er og den valgte kanoniske URL-en.
• Bing Crawl på https://app.amicited.com/reports/bing-webmasters/crawl eksponerer Bings gjennomsøkingsaktivitet og URL-nivåproblemer.
• Google Search Pages på https://app.amicited.com/reports/pages hjelper med å velge høyverdige landingssider og skiller sider med synlighet fra sider som er fraværende i søkedata.
• Directory View på https://app.amicited.com/reports/directory avslører seksjonsnivåmønstre og støtter dybde- og foreldreløse-undersøkelser.
• Data Health på https://app.amicited.com/features/data-health/ registrerer om tilkoblede bevis er fullstendige nok til å støtte trygge beslutninger.

Beslutningsregler

Terskler skaper funn; de erstatter ikke skjønn. Segmenter etter mal og forretningsmessig betydning: ti feil i en utsjekkingskategori kan bety mer enn tusen ødelagte arkivtagger.

Prioriter med påvirkning × innsats × tillit. Skåre påvirkning fra 1–5 basert på berørte kvalifiserte URL-er og forretningsreiser. Skåre innsats fra 1–5 som en enkelhetsfaktor, hvor 5 betyr en liten, reversibel endring og 1 betyr et stort risikabelt program; registrer også det ærlige estimatet i timer eller dager. Skåre tillit som 0,5 for en plausibel hypotese, 0,75 for gjentatte bevis, eller 1,0 for en reprodusert grunnårsak. Produktet gir et sorteringshjelpemiddel, ikke falsk presisjon.

Bruk avhengighetsoverstyringen: en rettelse som frigjør annet arbeid overgår en høyere skåre som ikke gjør det. Å fjerne en robots-blokkering før lansering kommer før polering av indekserte tittel-tagger. På samme avhengighetsnivå, adresser malomfattende årsaker før symptomer.

Leveranse: det prioriterte funnregisteret

Overlevere ett felles register, ikke en gjennomsøkereksport. Bruk én rad per grunnårsak og vedlegg URL-prøver separat.

Registeret er komplett når kritiske og større funn har eiere og estimater, blokkeringer har en sekvens, hypoteser er merket, og publiseringsbeslutningen er eksplisitt.

Hva går galt

En rapport med 200 elementer ingen kan handle på

Gjennomsøkereksporter forveksler observasjoner med beslutninger. Grupper gjentatte URL-er under malen eller regelen som forårsaker dem, gi et representativt utvalg, og tildel én eier. To hundre ødelagte URL-er produsert av én navigasjonskomponent er ett grunnårsaksfunn med målbar utstrekning, ikke to hundre oppgaver.

Rapportering av symptomer i stedet for årsaker

«Side ikke indeksert» er et symptom. Årsaken kan være en utilsiktet kanonisk URL, en foreldreløs mal, tynne parametervarianter, en mobilfeil eller en JavaScript-only-lenke. Et funn er ikke klart for prioritering før det identifiserer den kontrollerbare årsaken eller tydelig merker neste diagnostiske test.

Å revidere staging ved et uhell

Staging kan ha andre robots-regler, autentisering, data, maler, feature-flagg og vertsadferd. Registrer produksjonsopprinnelsen og Search Console-egenskapen øverst i hver eksport. Hvis en gjennomsøking må kjøres mot staging for lanseringssikring, merk den som en separat sammenligning og flett aldri dens målinger inn i produksjonsbaselinen.

Unngå også å telle bevisste ekskluderinger som tap, behandle sitemap-inkludering som bevis på indeksering, teste kun hjemmesiden, eller prioritere etter URL-antall alene. Definer det kvalifiserte settet, segmenter etter mal, og behold akseptbevis.

Neste fase

Neste fase, AI accessibility and agent readiness , trenger et teknisk stabilt utvalg. Overlever den tiltenkte indekserbare beholdningen, rene representative URL-er for hver prioritert mal, rå og rendret HTML-sammenligninger, robots- og svarbevis, kanoniske beslutninger, kjente ekskluderinger og åpne funnsregisteret.

Ikke påstå at nettstedet er «teknisk sunt». Angi hvilke maler som bestod gjennomsøkings- og indeksportene, hvilke som fortsatt er blokkert, og om publisering kan fortsette. Neste eier godtar når de kan teste AI-spesifikke brukeragenter og uttrekk uten å gjenoppdage uløste søkegjennomsøkingsfeil.

FAQ

Hvor ofte bør vi gjenta en teknisk baseline-revisjon?

Kjør den før en migrering, redesign, domeneendring eller et stort publiseringsprogram, og gjenta berørte kontroller etter lansering. Overvåk kontinuerlig og gjenta en standard gjennomgang når maler, navigasjon, rendering eller kanoniske regler endres.

Hvilken indekseringsandel bør et sunt nettsted ha?

For bevisst kvalifiserte URL-er er 90 % eller mer startforventningen, 80–90 % trenger forklaring, og under 80 % er et funn. Ekskluder omdirigeringer, duplikater, filtre og bevisste noindex-sider fra nevneren.

Kan vi publisere innhold mens tekniske rettelser pågår?

Bare når nye URL-er er gjennomsøkbare, indekserbare, kanoniserte, internt lenket og ikke påvirket av feilen. Hvis oppdagelse eller utvelgelse er blokkert, sett på pause; nye URL-er utvider bare opprydningsarbeidet.

Trenger vi en gjennomsøker hvis Search Console er tilkoblet?

Ja. Search Console rapporterer hva Google har observert; en gjennomsøker tester det nåværende nettstedet og avslører lenker, svar, dybde, kanoniske URL-er og duplikater. Ingen av dem erstatter den andre.

Hvem eier rettelsene som blir funnet i revisjonen?

SEO-lederen eier registeret og akseptkriteriene. Utvikling eier vanligvis server-, renderings-, omdirigerings-, kanoniske- og HTTPS-rettelser; innholdsteam kan eie duplisering og lenking. Hvert element trenger én navngitt person.