Teknisk basislinje-revision

Fase P2 · Trin A — Forstå
Tidsramme: 2–4 timer for et let gennemløb, 1–2 arbejdsdage for et standard gennemløb eller 3–8 arbejdsdage for et dybt gennemløb.
Ejer: den tekniske SEO-lead. Engineering, analyse, indhold og lokalisering bidrager med beviser og accepterer rettelser inden for deres områder.

En teknisk basislinje-revision fastslår, om søgemaskiner kan nå, fortolke og udvælge de URL’er, som virksomheden forventer, de skal vise. Omfanget dækker crawl-kontroller, HTTP-svar, indeksering, kanoniske URL’er, links, rendering, international målretning og sikker levering. Resultatet er et prioriteret fundregister med navngivne ejere og accepttests, ikke en score.

Hvorfor denne fase kommer her

At publicere på et site med crawl- eller indekseringsproblemer forværrer skaden. Søgemaskiner opdager ofte en gentagen fejl på tværs af nye URL’er hurtigere, end de evaluerer og belønner indholdet. En ødelagt kanonisk skabelon kan pege alle artikler et andet sted hen; en robots-regel kan skjule en mappe; klientrenderet navigation kan skabe forældreløse sider for en ikke-JavaScript-klient. Hver ny side forstørrer det berørte sæt og gør reparation mere risikabel.

Ret fundamentet først. Rækkefølgen er crawlbarhed → indekserbarhed → indholdskvalitet → performance, fordi hvert lag er en port. Crawlbarhed betyder, at en crawler kan opdage og anmode om en URL; indekserbarhed betyder, at den tilgængelige URL er berettiget til inklusion. Først da bør indholdskvalitet og performance vurderes. En hurtig side blokeret af robots.txt kan ikke konkurrere, og titel-tags betyder intet på utilgængelige sider.

Denne fase bruger omfang, prioritetsrejser, markeder og risici fra Opdagelse og mål . At udføre den tidligere giver et crawl uden forretningskontekst. At springe den over lader research og produktion målrette skabeloner, der ikke pålideligt kan komme ind i indekset.

Inputs og outputs

Inputs definerer det tilsigtede site, ikke blot hvad en crawler finder. Outputs fortæller den næste ejer, hvilke URL’er der er sikre at teste, og hvilke der forbliver blokerede.

Vælg revisionsdybden

Vælg dybde før crawl. Estimatet forudsætter, at adgang er klar, og ekskluderer implementering.

Tjeklisten

Arbejd i rækkefølge. En mislykket port kan ugyldiggøre senere stikprøver, så registrér fejlen og dens omfang før du fortsætter.

1. Bekræft, at målet er produktion

Hvad skal gøres: verificér scheme, host, robots-fil, analyse-ejendom, Search Console-ejendom og sitemap-host. Hvorfor det er vigtigt: Staging kan se rent ud, mens produktion forbliver defekt. Sådan gør du: Opløs den aftalte kanoniske host, sammenlign prioritetssider og svar-headere, og registrér crawl-oprindelsen. Værktøj: browser, crawler-konfiguration, Search Console-vælger. Færdig når: registret navngiver den bekræftede produktions-origin og -ejendom, uden staging-hostnavn i seeds eller eksporter.

2. Test robots.txt før crawl

Hvad skal gøres: inspicér hver produktionshosts /robots.txt og refererede sitemaps. Hvorfor det er vigtigt: En disallow-regel forhindrer crawl før indhold kan evalueres. Sådan gør du: Sammenlign Disallow-mønstre med det tilsigtede inventar, test matchende og ikke-matchende URL’er, og skeln mellem crawl-blokering og noindex. Værktøj: rå respons og robots-tester. Færdig når: robots returnerer 200, tilsigtede blokeringer har årsager, indekserbare stikprøver er tilladt, og én utilsigtet blokering udløser et kritisk fund.

3. Afstem sitemaps med reelle URL’er

Hvad skal gøres: sammenlign indsendte sitemaps med det kanoniske, indekserbare inventar. Hvorfor det er vigtigt: Et sitemap bør navngive URL’er, sitet ønsker udvalgt, ikke omdirigeringer, fejl eller dubletter. Sådan gør du: Normalisér indtastninger, sammenlign antal efter skabelon, og tag derefter stikprøver af tilføjelser og udeladelser i Sitemaps og indeksering . Værktøj: https://app.amicited.com/reports/google-search/sitemaps-indexing og crawl-eksporter. Færdig når: dækning er mindst 95 %, 0 indtastninger omdirigerer eller giver fejl, og hvert hul har en årsag eller ejer.

4. Mål statuskode-fordeling

Hvad skal gøres: klassificér svar som 2xx, 3xx, 4xx eller 5xx. Hvorfor det er vigtigt: Fejl stopper hentning, og omdirigeringer tilføjer hop. Sådan gør du: Følg og rapporter omdirigeringer, segmentér efter skabelon, og sammenlign med Bing Crawl . Værktøj: https://app.amicited.com/reports/bing-webmasters/crawl, crawler og overvågning. Færdig når: indekserbare URL’er returnerer 200; interne fejl, løkker og kæder er nul; og bevidste omdirigeringer er dokumenteret.

5. Fjern omdirigeringskæder og -løkker

Hvad skal gøres: spor omdirigeringer til deres endelige svar. Hvorfor det er vigtigt: Hop sænker opdagelse; en løkke når aldrig indhold. Sådan gør du: Eksportér stier, opdatér interne links til endelige kanoniske URL’er, og konsolidér regler. Værktøj: omdirigeringsrapport og header-tjek. Færdig når: interne links går direkte, legacy-omdirigeringer tager ét hop, og ingen løkke eller kæde forbliver.

6. Fastlæg det berettigede indekseringsforhold

Hvad skal gøres: sammenlign Googles indekstilstand med bevidst berettigede URL’er. Hvorfor det er vigtigt: Inkludering af omdirigeringer, filtre, dubletter eller noindex-sider gør forholdet meningsløst. Sådan gør du: Opbyg den berettigede nævner, inspicér prioriterede stikprøver i URL-inspektion , og gruppér eksklusioner efter skabelon. Værktøj: https://app.amicited.com/reports/google-search/url-inspection, Search Console og inventar. Færdig når: mindst 90 % er indekseret, eller hvert hul har en rodårsagsejer; under 80 % er et større fund.

7. Verificér kanonisk korrekthed

Hvad skal gøres: sammenlign erklærede, endelige og Google-udvalgte kanoniske URL’er. En kanonisk URL er den foretrukne version blandt lignende URL’er. Hvorfor det er vigtigt: En forkert konsoliderer signaler væk fra den tilsigtede side. Sådan gør du: Test unikke siders selv-referencer, bevidste kryds-kanoniske URL’er og konsistens på tværs af HTML, sitemaps, omdirigeringer og links. Værktøj: kanonisk rapport og https://app.amicited.com/reports/google-search/url-inspection. Færdig når: 100 % af unikke indekserbare sider navngiver én absolut, 200, indekserbar kanonisk URL, med hver udvalgte uoverensstemmelse forklaret.

8. Find dublet- og næsten-dublet-klynger

Hvad skal gøres: gruppér URL’er med identisk eller væsentligt overlappende hovedindhold og samme søgeformål. Hvorfor det er vigtigt: Dubletter splitter interne signaler og tvinger søgemaskiner til at vælge en version, virksomheden måske ikke foretrækker. Sådan gør du: Sammenlign eksakte hashes, normaliseret tekstlighed, titler, kanoniske URL’er, parametre og skabelonformål; vælg derefter konsolidering, differentiering, noindex eller fjernelse. Værktøj: crawlers dubletrapporter, sideinventar og Google Search-sider . Færdig når: ingen klynge indeholder mere end én uforklaret kanonisk indekserbar URL, der tjener samme hensigt, og hver accepteret variant har et distinkt formål registreret.

9. Find forældreløse sider og mål linkdybde

Hvad skal gøres: sammenlign crawler-URL’er med sitemaps, analyse, Search Console, CMS-eksporter og backlinks for at finde sider uden crawlbart internt link. Mål den korteste kliksti fra forsiden. Hvorfor det er vigtigt: En forældreløs side kan optræde i et sitemap, men modtage lidt intern kontekst eller autoritet; overdreven dybde gør opdagelse skrøbelig. Sådan gør du: Sammenlign kilder, inspicér mappemønstre i Mappevisning , og spor navigation, brødkrummer, hubs og kontekstuelle links. Værktøj: https://app.amicited.com/reports/directory og et multi-kilde-crawl. Færdig når: tilsigtet antal forældreløse sider er nul, prioritetssider er inden for tre klik fra forsiden, andre tilsigtede indekserbare sider er inden for fem, og hver undtagelse har en bevidst opdagelsesrute.

10. Sammenlign renderet og ikke-JavaScript HTML

Hvad skal gøres: sammenlign det indledende serversvar med siden efter JavaScript udføres. Hvorfor det er vigtigt: En browser kan vise indhold og links, som en ikke-JavaScript-klient aldrig modtager. Sådan gør du: Hent repræsentative sider med scripts deaktiveret, inspicér rå HTML, sammenlign derefter overskrifter, hovedtekst, links, kanonisk URL, robots-direktiver, strukturerede data og status efter rendering. Værktøj: crawler i HTML- og renderet tilstand samt browser-udviklerværktøjer. Færdig når: det indledende svar indeholder det primære indhold, kanonisk URL, indeks-direktiver og crawlbare navigation, der er nødvendig for at opdage prioritetssider; enhver JavaScript-only-afhængighed er eksplicit accepteret og testet på tværs af skabeloner.

11. Validér hreflang hvor relevant

Hvad skal gøres: verificér annotationer, der forbinder sproglige eller regionale ækvivalenter. Hvorfor det er vigtigt: Ufuldstændige eller modstridende klynger kan få søgemaskiner til at ignorere målretning og vise den forkerte markedsversion. Sådan gør du: Test gyldige sprog-region-koder, absolutte kanoniske URL’er, selv-referencer, gensidige returlinks, x-default hvor det har en reel fallback-rolle, og indekserbarhed af hvert mål. Værktøj: crawlers hreflang-rapport og URL-stikprøver. Færdig når: ugyldige koder, manglende selv-referencer, manglende returlinks, ikke-kanoniske mål, omdirigeringer og fejl alle er nul. Hvis sitet ikke har lokaliserede ækvivalenter, notér “ikke relevant” frem for at opfinde annotationer.

12. Test paginering og crawl-stier

Hvad skal gøres: verificér, at multi-side kategori- eller arkivsekvenser eksponerer crawlbare links og nyttige unikke URL’er. Hvorfor det er vigtigt: Uendelig scroll eller knap-only-loading kan skjule dybere elementer, mens kanonisering af hver side til side ét kan fjerne distinkt inventar fra opdagelse. Sådan gør du: Deaktivér JavaScript, følg næste- og nummererede links, inspicér status, kanonisk og robots-direktiver, og test den sidste side og out-of-range-parametre. Værktøj: ikke-renderet crawl og browser. Færdig når: hvert tilsigtet element er tilgængeligt via ankerlinks, hver nyttig side selv-kanoniserer, ugyldige sidetal returnerer en passende fejl frem for en blød 200, og ingen sekvens skaber et ubegrænset URL-rum.

13. Tjek mobil-paritet

Hvad skal gøres: sammenlign mobil- og desktop-levering for indhold, links, metadata, direktiver, strukturerede data og responsstatus. Hvorfor det er vigtigt: Google evaluerer primært mobilrepræsentationen; at skjule meningsfuldt indhold eller links kun på mobil ændrer, hvad det kan forstå. Sådan gør du: Crawl med desktop- og smartphone-user-agenter og sammenlign repræsentative skabeloner, ikke kun visuelle skærmbilleder. Værktøj: sammenkoblede crawls, mobil URL-inspektion og browsers responsiv tilstand. Færdig når: alt indekserbart indhold og crawlbare links, der kræves for mening og opdagelse, er ækvivalente, med nul mobil-only-blokeringer, kanoniske forskelle eller fejlsvar.

14. Håndhæv HTTPS og fjern mixed content

Hvad skal gøres: verificér sikker levering, host-omdirigeringer, certifikater, kanonisk scheme, interne URL’er og ressourcer indlæst over HTTP. Mixed content betyder, at en HTTPS-side anmoder om en usikker ressource. Hvorfor det er vigtigt: Usikre anmodninger kan blokeres, eksponere brugere og skabe inkonsistente URL-signaler. Sådan gør du: Crawl alle HTTP-varianter, inspicér certifikatdækning og browsersikkerhedsfejl, og søg i renderet ressourceanmodninger. Værktøj: crawler, browsers sikkerhedspanel og serverkonfiguration. Færdig når: hver HTTP-side omdirigerer én gang til sin matchende HTTPS-URL, alle kanoniske URL’er og interne links bruger HTTPS, certifikater er gyldige for hver live host, og aktive eller passive mixed content-anmodninger er nul.

Værktøjer i AmICited

Brug produktrapporter som checkliste-beviser, ikke som en crawl-erstatning.

• Sitemaps og indeksering på https://app.amicited.com/reports/google-search/sitemaps-indexing viser indsendt sitemap-status, advarsler, fejl og indekseringshandlinger.
• URL-inspektion på https://app.amicited.com/reports/google-search/url-inspection giver Googles live-afgørelse for udvalgte URL’er og den valgte kanoniske URL.
• Bing Crawl på https://app.amicited.com/reports/bing-webmasters/crawl viser Bings crawler-aktivitet og URL-niveau-problemer.
• Google Search-sider på https://app.amicited.com/reports/pages hjælper med at udvælge højværdi-landingssider og adskille sider med synlighed fra sider, der er fraværende i søgedata.
• Mappevisning på https://app.amicited.com/reports/directory afslører sektionsniveaumønstre og understøtter dybde- og forældreløs-undersøgelser.
• Data Health på https://app.amicited.com/features/data-health/ registrerer, om tilsluttede beviser er fuldstændige nok til at understøtte sikre beslutninger.

Beslutningsregler

Tærskelværdier skaber fund; de erstatter ikke dømmekraft. Segmentér efter skabelon og forretningsmæssig betydning: ti checkout-kategori-fejl kan betyde mere end tusind ødelagte arkiv-tags.

Prioritér med påvirkning × indsats × tillid. Score påvirkning fra 1–5 baseret på berørte berettigede URL’er og forretningsrejser. Score indsats fra 1–5 som en lethedsfaktor, hvor 5 betyder en lille, reversibel ændring og 1 betyder et stort risikabelt program; registrér også det ærlige estimat i timer eller dage. Score tillid som 0,5 for en plausibel hypotese, 0,75 for gentagne beviser eller 1,0 for en reproduceret rodårsag. Produktet giver en ordningshjælp, ikke falsk præcision.

Anvend afhængighedsoverstyringen: en rettelse, der frigør andet arbejde, overgår en større score, der ikke gør. At fjerne en robots-blokering før lancering kommer før polering af indekserede titel-tags. På samme afhængighedsniveau, adressér skabelon-dækkende årsager før symptomer.

Leverance: det prioriterede fundregister

Overgiv ét delt register, ikke en crawler-eksport. Brug én række pr. rodårsag og vedhæft URL-stikprøver separat.

Registret er komplet, når kritiske og større fund har ejere og estimater, blokeringer har en sekvens, hypoteser er mærket, og publiceringsbeslutningen er eksplicit.

Hvad går galt

En 200-punkts rapport, ingen kan handle på

Crawler-eksporter forveksler observationer med beslutninger. Gruppér gentagne URL’er under den skabelon eller regel, der forårsager dem, giv en repræsentativ stikprøve, og tildel én ejer. To hundrede ødelagte URL’er produceret af én navigationskomponent er ét rodårsagsfund med et målbart omfang, ikke to hundrede opgaver.

Rapportering af symptomer i stedet for årsager

“Side ikke indekseret” er et symptom. Årsagen kan være en utilsigtet kanonisk URL, en forældreløs skabelon, tynde parametervarianter, en mobilfejl eller et JavaScript-only-link. Et fund er ikke klar til prioritering, før det identificerer den kontrollerbare årsag eller tydeligt mærker den næste diagnostiske test.

Revision af staging ved et uheld

Staging kan have andre robots-regler, autentificering, data, skabeloner, feature flags og host-adfærd. Registrér produktions-originen og Search Console-ejendommen øverst i hver eksport. Hvis et crawl skal køre mod staging til release-sikring, mærk det som en separat sammenligning og sammenlæg aldrig dens målinger med produktionsbasislinjen.

Undgå også at tælle bevidste eksklusioner som tab, at behandle sitemap-inklusion som bevis på indeksering, kun at teste forsiden eller at prioritere efter URL-antal alene. Definér den berettigede mængde, segmentér efter skabelon, og behold acceptbeviser.

Næste fase

Den næste fase, AI-tilgængelighed og agent-beredskab , har brug for en teknisk stabil stikprøve. Overgiv det tilsigtede indekserbare inventar, rene repræsentative URL’er for hver prioritetsskabelon, rå og renderet HTML-sammenligninger, robots- og responsbeviser, kanoniske beslutninger, kendte eksklusioner og registret over åbne fund.

Påstå ikke, at sitet er “teknisk sundt.” Angiv, hvilke skabeloner der bestod crawl- og indeksportene, hvilke der forbliver blokerede, og om publicering kan fortsætte. Den næste ejer accepterer, når de kan teste AI-specifikke user-agenter og ekstraktion uden at genopdage uløste søge-crawl-defekter.

FAQ

Hvor ofte skal vi gentage en teknisk basislinje-revision?

Kør den før en migration, et redesign, et domæneskifte eller et stort publiceringsprogram, og gentag derefter berørte kontroller efter udgivelsen. Overvåg løbende, og gentag et standard-gennemløb, når skabeloner, navigation, rendering eller kanoniske regler ændres.

Hvilket indekseringsforhold skal et sundt site have?

For bevidst berettigede URL’er er 90 % eller mere startforventningen, 80–90 % kræver forklaring, og under 80 % er et fund. Ekskludér omdirigeringer, dubletter, filtre og bevidste noindex-sider fra nævneren.

Kan vi publicere indhold, mens tekniske rettelser er i gang?

Kun når nye URL’er er crawlbare, indekserbare, kanoniserede, internt linkede og upåvirkede af defekten. Hvis opdagelse eller selektion er blokeret, sæt på pause; nye URL’er udvider kun oprydningen.

Har vi brug for en crawler, hvis Search Console er tilsluttet?

Ja. Search Console rapporterer, hvad Google observerede; en crawler tester det nuværende site og afslører links, svar, dybde, kanoniske URL’er og dubletter. Ingen erstatter den anden.

Hvem ejer rettelser fundet i revisionen?

SEO-lead ejer registret og acceptkriterierne. Engineering ejer typisk server-, renderings-, omdirigerings-, kanoniske- og HTTPS-rettelser; indholdsteams kan eje dubletter og linking. Hvert element har brug for én navngiven person.