Tjekliste til styring af crawl-budget

Crawl-budget er den praktiske grænse for, hvor meget en søgemaskine er villig og i stand til at gennemgå på et websted over tid. At styre det betyder at reducere forespørgsler, der ikke kan forbedre opdagelse eller indeksering, og derefter gøre vigtige URL’er lettere at finde og billigere at hente.

Tjekliste: styring af crawl-budget. Tidsramme: 1–2 arbejdsdage til diagnose, derefter 1–3 engineering-sprints til godkendte rettelser. Ejer: teknisk SEO-ansvarlig. Bidragydere: platformingeniør, CDN- eller infrastrukturejer, analyseingeniør og merchandising- eller indholdsejer for eventuelt påvirket URL-område. Frigivelsesansvar: teknisk SEO-ansvarlig og engineering-ejer i fællesskab.

Vær ærlig om omfanget: et sundt websted med 2.000 eller 8.000 kanoniske sider har næsten aldrig et crawl-budget-projekt. Det har et prioriterings-, linknings-, kvalitets- eller indekseringsproblem. Start denne tjekliste, når et stort eller hurtigt ændrende websted har dokumentation for crawler-spild, forsinket opdagelse, gentagen gennemgang af lavværdi-URL’er eller belastning af værten — ikke fordi en crawlerrapport indeholder et stort tal.

Hvorfor denne fase, og hvorfor her

Selvom dette er en selvstændig tjekliste snarere end en nummereret fase, forbruger den den tekniske basislinjeaudit : kanoniske regler, statuskode-fund, renderingsadfærd, webstedsarkitektur, sitemap-inventar og indeksdækning. Den har også brug for et godkendt indholdsinventar, fordi “spild” ikke kan defineres, før virksomheden har sagt, hvilke URL’er der skal findes, opdateres og indekseres.

Kør den, efter at teamet kan skelne værdifulde kanoniske sider fra filtre, dubletter, udløbet inventar, intern søgning og administrative ruter. At køre den tidligere opfordrer til blanketblokering. At køre den efter en stor programmatisk udrulning, overflytning eller udgivelse af facetnavigation er for sent: crawlere kan allerede være fanget i et i realiteten ubegrænset URL-rum.

Hvis den springes over på et virkelig stort websted, kan nye og ændrede prioriterede URL’er vente bag endeløse parameterkombinationer, fejlsider, omdirigeringskæder og dubletter. Hvis den køres på et lille sundt websted, forbruger den engineering-tid uden at adressere den reelle begrænsning. Afhængighedsargumentet er enkelt: klassificering kommer før kontrol, og dokumentation kommer før regler.

Inputs og outputs

Outputs er kontrakten med engineering og den næste målecyklus. “Forbedr crawleffektivitet” er ikke et leverance.

Tjeklisten

Registrér BESTÅET, IKKE BESTÅET eller N/A og vedlæg dokumentation for hvert punkt. Hvert punkt er først færdigt, når dets “Færdig når”-betingelse kan observeres.

1. Bevis at crawl-budget er begrænsningen

Hvad: beslut, om dette arbejde fortjener et projekt. Hvorfor: crawl-budget får ofte skylden, når en side faktisk er af lav kvalitet, forældreløs, ikke-kanonisk, blokeret eller bevidst udelukket. Hvordan: sammenlign antal kanoniske URL’er, daglig URL-oprettelse, serverhelbred, sidste crawl-datoer, opdagelsesforsinkelse, dækningsårsager og andelen af verificerede bot-forespørgsler brugt uden for det kanoniske inventar. Segmentér efter mappe og skabelon; et webstedsdækkende gennemsnit skjuler en enkelt løbsk sektion. Værktøj: log-pipeline, crawler, søgemaskiners dækningsrapporter, sitemap-eksporter og udgivelseskalender. Færdig når: en underskrevet diagnose navngiver mindst én målt begrænsning eller lukker tjeklisten som “ikke væsentlig” med dokumentation og en mere passende næste handling.

2. Opbyg et troværdigt bot-forespørgselsdatasæt

Hvad: opret én normaliseret forespørgselstabel for analysevinduet. Hvorfor: user-agent-strenge kan forfalskes, samplede analyser udelader botter, og CDN-logge kan afvige fra oprindelseslogge. Logfilanalyse betyder at undersøge serveradgangsposter for at se, hvad crawlere faktisk anmodede om. Hvordan: kombinér CDN- og oprindelsesdata hvor nødvendigt, normalisér vært og URL-kodning, fjern statiske aktiver medmindre rendering er inden for omfang, verificér større søgebotter med udbyderens publicerede verifikationsmetode, og behold status, bytes, svartid og cache-resultat. Værktøj: CDN- eller webserverlogge, DNS-verifikation, SQL eller en loganalysator. Færdig når: datointerval og opbevaring er dokumenteret, kendte botter er adskilt fra uverificerede agenter, totaler stemmer overens med råposter, og den samme forespørgsel kan reproducere alle diagrammer i diagnosen.

3. Mål hvor forespørgsler spildes

Hvad: klassificér hver crawler-forespørgsel som nyttig kanonisk, dublet, omdirigering, fejl, blokeret, parameter, facet, intern søgning, blød 404, aktiv eller ukendt. En blød 404 er en side, der returnerer 200 OK, men opfører sig som et manglende eller tomt resultat. Hvorfor: samlet crawl-volumen kan ikke vise, om crawlere opfrisker inventar eller looper gennem værdiløse tilstande. Hvordan: join forespørgsler til crawl- og kanonisk inventar, gruppér efter normaliseret sti og parametersignatur, rangér derefter mønstre efter forespørgselsantal og serveromkostning. Afstem disse mønstre med dækningsårsager såsom opdaget men ikke indekseret, gennemgået men ikke indekseret, dublet, blokeret og blød 404; dækning forklarer en søgemaskines rapporterede resultat, mens logge beviser forespørgsler. Inspectér den ukendte gruppe manuelt i stedet for at tvinge den ind i en bekvem etiket. Værktøj: verificerede logge, dækningseksport, webcrawler, kanonisk eksport og responsprofilering. Færdig når: mindst 95 % af relevante bot-forespørgsler har en gennemgået klassificering, den resterende ukendte del er listet, og de største spildmønstre har eksempel-URL’er, dækningsresultater og ejere.

4. Inddæm facetter og parametre ved kilden

Hvad: styr filter-, sorterings-, paginerings-, sporings-, sessions- og søgeparametre. Facetnavigation lader brugere kombinere filtre såsom mærke, farve og størrelse; ukontrollerede kombinationer kan skabe et i realiteten uendeligt crawl-rum. Hvorfor: at blokere en crawler efter at skabeloner har genereret millioner af links behandler symptomet, mens opdagelse, brugeradfærd, analyser og andre botter forbliver eksponerede. Hvordan: tildel hver parameter en funktion og én politik: indekserbar landingsside, kanonisk dublet, noindex-side, omdirigering, aflinket tilstand eller blokeret mønster. Brug stabil parameterrækkefølge, forhindr tomme og modstridende kombinationer, og fjern sporings- eller sessionsparametre fra interne links. Kanonisér ikke en side til et mål med væsentligt forskelligt indhold blot for at undertrykke den. Værktøj: parameterregister, skabelonkilde, crawler med URL-mønsterrapporter, logge og automatiserede URL-tests. Færdig når: hver observeret parameter har én godkendt politik, crawlbare skabeloner udsender kun tilladte kombinationer, forbudte kombinationer har testdækning, og log-volumen for de målrettede mønstre falder ved det aftalte kontrolpunkt.

5. Eliminér uendelige rum og crawl-fælder

Hvad: luk ruter, der kan generere ubegrænsede datoer, kalendere, paginering, ID’er, kasusvarianter, stisegmenter eller rekursive filtre. Hvorfor: en crawler kan blive ved med at opdage syntaktisk nye URL’er, selv når hver side indeholder det samme tomme eller duplikerede resultat. Hvordan: sæt endelige grænser, returnér 404 eller 410 for umulige tilstande, link kun til gyldige intervaller, normalisér kasus og regler for efterfølgende skråstreg, omdirigér eksakte dubletter én gang, og stop med at generere næste-side-links ud over det sidste resultatsæt. Test misdannede og ekstreme værdier, ikke kun den glade vej. Værktøj: syntetisk URL-generator, crawler, logge, router-tests og edge-regeltests. Færdig når: hver generator har et dokumenteret maksimum, tilstande uden for interval returnerer det tilsigtede svar, ingen testet rute skaber en ny ubegrænset sekvens, og berørte forespørgselsmønstre falder uden at blokere værdifulde sider.

6. Korrigér bløde 404’er, fejl og omdirigeringsspild

Hvad: få svarstatuskoder til at beskrive det faktiske resultat. Hvorfor: en 200 tom side beder crawlere om at parse og vurdere indhold, der burde være erklæret manglende; gentagne 5xx-svar forbruger kapacitet og kan få en vært til at se upålidelig ud; kæder bruger flere forespørgsler på at nå én destination. Hvordan: returnér 404 for manglende URL’er, 410 for bevidst fjernede ressourcer når passende, 200 kun for substantielle sider og en enkelt omdirigering til den endelige kanoniske destination for flyttede URL’er. Reparér interne links, der peger ind i omdirigeringer eller fejl. Værktøj: logge, crawler, HTTP-testpakke, overvågning og ruteinventar. Færdig når: samplede tomme resultater ikke længere returnerer 200, prioriterede ruter har ingen omdirigeringskæde, interne links løses direkte, og fejlratetærsklen i beslutningsreglerne bestås i to på hinanden følgende målevinduer.

7. Gør kanoniske og indekskontrolsignaler konsistente

Hvad: justér svar, kanonisk URL , meta robots, HTTP robots-headere, interne links og sitemap-medlemskab. Hvorfor: modstridende signaler forårsager gentagne genbesøg: en URL kan være indsendt i et sitemap, kanoniseret et andet sted, linket i hele navigationen og blokeret fra det direktiv, der forklarer dens status. Hvordan: opret en regelmatrix for hver URL-klasse og test det renderede produktionssvar. Brug robots.txt til at styre crawleradgang, ikke som en pålidelig fjernelsesmekanisme; en blokeret URL kan ikke afsløre et noindex-direktiv på sideniveau for en crawler, der aldrig henter den. Værktøj: crawler, rå og renderet HTML, header-inspektør, robot-tester og URL-inspektion. Færdig når: 100 % af prioritetsprøverne og alle skabelontestcases matcher én sammenhængende regel, uden at nogen indekserbar kanonisk URL er blokeret, og uden at noget ekskluderet mønster fremmes gennem sitemaps eller primær navigation.

8. Rens XML-sitemaps til en prioriteret feed

Hvad: publicér kun kanoniske, indekserbare 200-URL’er og sandfærdige ændringsdatoer i hvert XML-sitemap . Hvorfor: et sitemap er et opdagelsessignal, ikke et arkiv over alle URL’er, CMS’et har produceret. Omdirigeringer, dubletter, fejl og uændrede lastmod-tidsstempler fortynder signalet og slører dækningssammenligninger. Hvordan: afstem sitemap-URL’er med det kanoniske inventar, del filer op efter stabile diagnostiske enheder såsom indholdstype eller mappe, fjern ekskluderede URL’er, og opdatér lastmod kun for substantielle sideændringer. Indsend ændrede sitemaps og registrér download, advarsler og fejl. Værktøj: sitemap-parser, CMS-eksport, logge og søgemaskiners sitemap-rapporter. Færdig når: hver indsendt URL returnerer 200, er selv-kanonisk og indekserbar, ekskluderinger er nul, lastmod består en samplet indholdsændringskontrol, og indsendte antal stemmer overens med det godkendte inventar.

9. Brug interne links til at trække prioriterede sider tættere på

Hvad: reparér forældreløse sider og reducér klikafstanden til højværdi-URL’er gennem nyttig intern linking . Crawl-dybde er antallet af linktrin, en crawler behøver for at nå en side fra en valgt startsides. Hvorfor: at blokere spild fortæller ikke en crawler, hvad den skal besøge næste gang; stabile HTML-links fra stærke, ofte besøgte sider gør. Hvordan: beregn dybde og indgående links fra forsiden og relevante hubs, tilføj kontekstuelle eller navigationsmæssige links hvor brugere har gavn af det, udskift links til omdirigerede URL’er, og sørg for at paginering eksponerer dybere inventar. Flad ikke alt ud i en footer. Værktøj: link-graf-crawler, skabeloner, logge og søgeydelse pr. mappe. Færdig når: hver prioritets-URL har mindst ét crawlbart indgående link, ingen prioritets-forældreløs side er tilbage, aftalte prioritetsskabeloner er inden for tre linktrin af en relevant hub, og logge bekræfter at nyligt linkede prøver opdages eller genbesøges.

10. Beskyt værtskapacitet og renderingsstier

Hvad: hold crawler-forespørgsler hurtige og vellykkede uden at servere søgebotter en væsentligt anderledes side. Hvorfor: crawl-efterspørgsel kan ikke kompensere for en vært, der time-out’er, rate-limiter legitime crawlere vilkårligt eller kræver dyr rendering for grundlæggende indhold og links. Hvordan: sammenlign svartid og fejl efter bot, rute, cache-status og skabelon; cache sikre svar; fjern dyre forespørgselsstier; bevar essentiel HTML og links i det indledende svar; og test firewall- og CDN-regler med verificerede botter. Værktøj: applikationsydelsesovervågning, CDN-analyser, logge, oppetidstests og renderet sideinspektion. Færdig når: værten opfylder de aftalte svar- og fejltærskler under forventet belastning, verificerede crawlere udfordres ikke ved et uheld, og prioritetsindhold plus links er til stede uden brugerinteraktion.

11. Rul ud efter mønster og verificér afvejningen

Hvad: udgiv det mindste sammenhængende regelsæt, sammenlign derefter før og efter. Hvorfor: en global robot-, kanonisk-, routing- eller navigationsændring kan fjerne værdifulde longtail-sider hurtigere end den fjerner spild. Hvordan: start med ét målbart URL-mønster eller én mappe, bevar en kontrol hvor praktisk muligt, annotér udgivelsen, og sammenlign bot-forespørgsler, fejl, prioritets-gencrawlingsforsinkelse, dækning, visninger og serverbelastning efter en komplet crawl-cyklus. Hold tilbagerulningsinstruktioner ved siden af reglen. Værktøj: implementeringslog, serverlogge, dækningsrapporter, AmICited-rapporter og overvågning. Færdig når: målspildet forbedres, prioritetsopdagelse og -indeksering ikke forringes ud over den erklærede tolerance, ejeren godkender resultatet, og den næste udrulnings- eller tilbagerulningsbeslutning er registreret.

Værktøjer i AmICited

AmICited leverer søgemaskine- og ydelsesdokumentation omkring diagnosen. Rå serverlogge forbliver den primære kilde for forespørgselsniveauadfærd på tværs af botter.

1. Åbn Bing Crawl på den live Bing-crawl-rapport for at gennemgå Bings crawl-aktivitet og rapporterede URL-problemer. Indfang intervallet, problemtypen, eksempel-URL’er og eksporttidspunkt; generalisér ikke Bing-adfærd til alle crawlere.

2. Brug Sitemaps og indeksering på sitemap-rapporten til at sammenligne indsendte antal, sidste download, advarsler og fejl, indsend et renset sitemap eller anmod om indeksering af en afgrænset batch af ændrede prioritets-URL’er. En anmodning fremskynder genovervejelse; den gør ikke en blokeret eller lavkvalitetsside indekserbar.

3. Tjek repræsentative vindere, spildmønstre og reparerede sider i URL-inspektion på URL-inspektionsrapporten . Registrér den erklærede og valgte kanoniske URL, dækningsafgørelse, sidste crawl og inspektionstidspunkt. Dens dækningsvisning er en voksende stikprøve, ikke en komplet crawl-budget-rapport.

4. Åbn Google Search-kataloger på katalograpporten for at sammenligne klik og visninger pr. sektion, før du begrænser en mappe eller ændrer dens links. En sektion med lav trafik kan stadig være strategisk nødvendig; brug denne rapport til at vurdere søgepåvirkning, ikke til at erklære crawl-spild alene.

Beslutningsregler: hvordan dårligt ser ud i tal

Disse er operationelle udløsere for denne tjekliste, ikke universelle søgemaskinegrænser. Erstat dem kun med en dokumenteret webstedsbasislinje og en godkendt risikotolerance.

Åbn ikke et crawl-budget-projekt udelukkende fordi webstedet krydser en række for URL-antal. Omvendt, afvis ikke et websted med 20.000 sider, hvis kalenderfælde genererer millioner af distinkte URL’er. Dokumentation for begrænset opdagelse eller spild er den afgørende faktor.

Leverance

Overgiv en versionsstyret pakke, ikke et dias med “crawl optimeret”:

• crawl-budget-summary.md: omfang, beslutning, bot-verifikationsmetode, analysevindue, resultater, godkendte behandlinger, risici, udrulningsrækkefølge og tilbagerulningsudløsere.
• crawl-pattern-register.csv: normaliseret mønster, eksempel-URL, formål, forespørgselsantal, andel, svar, kanonisk tilstand, sitemap-tilstand, indgående links, forretningsværdi, behandling, ejer og status.
• priority-url-sample.csv: mindst 20 URL’er med basislinje- og kontrolpunktsfelter for opdagelse, sidste crawl, indeksafgørelse, dybde, indgående links, svar og valgt kanonisk.
• sitemap-reconciliation.csv: indsendt URL, inventartilstand, svar, kanonisk, indekserbarhed, lastmod-validering, handling og dokumentation.
• monitoring-spec.md: forespørgsler, dashboards, tærskler, ejere, kadence, alarmruter, kontrolpunktsdatoer og opbevaring.

Den tekniske SEO-ansvarlige ejer pakken; engineering godkender rute- og infrastrukturændringer; indholds- eller merchandising-ejeren godkender enhver beslutning, der fjerner en opdagelig brugersti eller indekserbar landingsside.

Hvad går galt

Teamet optimerer et lille websted. Ingeniører bruger et sprint på at blokere parametre, mens vigtige sider forbliver tynde eller forældreløse. Luk tjeklisten som ikke væsentlig og omdirigér arbejdet til indhold, linking eller indekserbarhed.

Robots.txt bliver et sletteværktøj. Blokerede URL’er kan forblive kendte, og crawlere kan ikke hente deres direktiver på sideniveau. Definér den tilsigtede livscyklus først, fjern intern generering, og brug den svar-, omdirigerings-, kanoniske- eller noindex-adfærd, der matcher den.

Hver facet behandles som en dublet. En mærke-og-kategori-kombination med reel efterspørgsel kan være en nyttig landingsside; en sorteringsrækkefølge er det normalt ikke. Beslut på mønsterniveau ved hjælp af efterspørgsel og indholdsdistinktion.

Et kanonisk tag forventes at stoppe crawling. Kanoniske URL’er udtrykker en foretrukken version, men dubletter kan stadig hentes for at evaluere forholdet. Fjern spildende links og generering i stedet for at stole på ét hint.

Sitemaps bliver database-dumps. Omdirigerede, udløbne, blokerede og ikke-kanoniske URL’er slører det inventar, teamet faktisk ønsker gennemgået. Afstem sitemap-medlemskab som en udgivelsesport.

Analyser forveksles med logge. Analyser på klientsiden registrerer sjældent søgebot-forespørgsler. Uden verificerede adgangslogge kan teamet ikke måle forespørgselsallokering eller svaromkostning.

Udrulningen blokerer indtægtssider. En bred parameter- eller stiregel fanger gyldige kategorier, lokaliserede sider, paginering eller kampagnedestinationer. Test positive og negative eksempler, iscenesæt ét mønster, og behold en hurtig tilbagerulning.

Succes betyder færre forespørgsler. Crawl-volumen kan falde, fordi værdifulde sider forsvandt fra opdagelse. En vellykket ændring reducerer spild, mens prioritetsopdagelse, indeksering og søgeefterspørgsel forbliver sunde.

Næste fase

Fodr mønsterregistret, sitemap-afstemningen, prioritetsprøven og overvågningstærsklerne ind i kontinuerlig opdatering og iteration . Den fase har brug for stabile opdagelsesstier og troværdige ændringssignaler; ellers kan en opdateret side publiceres korrekt, men vente uset bag crawl-fælder eller svage interne links.

Genåbn denne tjekliste efter en overflytning, platform- eller routingændring, udgivelse af facetnavigation, større inventarudvidelse, vedvarende fejlhændelse eller en aftalt tærskeloverskridelse. Kør ikke hele øvelsen igen på en kalender, så længe overvågningsbasislinjen forbliver ren.

FAQ

FAQ’en nedenfor dækker omfang, robotregler, parametre, sitemaps og gennemgangskadence. Det styrende princip er konsistent: klassificér URL-rummet først, brug forespørgselsdokumentation som det næste, og ændr crawlerkontroller kun når det tilsigtede bruger- og indekseringsresultat er eksplicit.