Sjekkliste for administrasjon av crawl-budsjett

Crawl-budsjett er den praktiske grensen for hvor mye gjennomsøking en søkemotor er villig og i stand til å gjøre på et nettsted over tid. Å administrere det handler om å redusere forespørsler som ikke kan forbedre oppdagelse eller indeksering, og deretter gjøre viktige URL-er lettere å finne og billigere å hente.

Sjekkliste: administrasjon av crawl-budsjett. Tidsramme: 1–2 arbeidsdager for diagnose, deretter 1–3 tekniske sprinter for godkjente rettelser. Eier: teknisk SEO-ansvarlig. Bidragsytere: plattformingeniør, CDN- eller infrastruktureier, analyseingeniør, og merchandising- eller innholdseier for berørt URL-område. Frigivelsesmyndighet: teknisk SEO-ansvarlig og teknisk eier i fellesskap.

Vær ærlig om omfanget: et sunt nettsted med 2 000 eller 8 000 kanoniske sider har nesten aldri et crawl-budsjett-prosjekt. Det har et problem med prioritering, lenking, kvalitet eller indekserbarhet. Start denne sjekklisten når et stort eller raskt skiftende nettsted har dokumentasjon på crawler-sløsing, forsinket oppdagelse, gjentatt gjennomsøking av lavverdige URL-er eller belastning på verten – ikke fordi en crawler-rapport inneholder et stort tall.

Hvorfor denne fasen, og hvorfor her

Selv om dette er en frittstående sjekkliste snarere enn en nummerert fase, bygger den på den tekniske basisrevisjonen : kanoniske regler, statuskode-funn, rendringsatferd, nettstedarkitektur, sitemap-beholdning og indeksdekning. Den trenger også en godkjent innholdsoversikt, fordi «sløsing» ikke kan defineres før virksomheten har sagt hvilke URL-er som bør bli funnet, oppdatert og indeksert.

Kjør den etter at teamet kan skille verdifulle kanoniske sider fra filtre, duplikater, utgått lager, internt søk og administrative ruter. Å kjøre den tidligere oppfordrer til generell blokkering. Å kjøre den etter en stor programmatisk utrulling, migrering eller utgivelse av fasettert navigering er for sent: crawlere kan allerede være fanget i et i praksis ubegrenset URL-rom.

Hvis den hoppes over på et virkelig stort nettsted, kan nye og endrede prioriterte URL-er vente bak endeløse parameterkombinasjoner, feilsider, omdirigeringskjeder og duplikater. Hvis den kjøres på et lite sunt nettsted, bruker den ingeniørtid uten å adressere den reelle begrensningen. Avhengighetsargumentet er enkelt: klassifisering kommer før kontroll, og dokumentasjon kommer før regler.

Inndata og utdata

Utdatene er kontrakten med utvikling og neste målesyklus. «Forbedre crawl-effektivitet» er ikke en leveranse.

Sjekklisten

Registrer BESTÅTT, IKKE BESTÅTT eller IKKEN/A og legg ved dokumentasjon for hvert punkt. Hvert punkt er fullført bare når betingelsen for «Ferdig når» kan observeres.

1. Bevis at crawl-budsjett er begrensningen

Hva: avgjør om dette arbeidet fortjener et prosjekt. Hvorfor: crawl-budsjett får ofte skylden når en side faktisk er av lav kvalitet, foreldreløs, ikke-kanonisk, blokkert eller bevisst ekskludert. Hvordan: sammenlign antall kanoniske URL-er, daglig URL-opprettelse, serverhelse, datoer for siste gjennomsøking, oppdagelsesforsinkelse, dekningsårsaker og andelen av verifiserte bot-forespørsler brukt utenfor den kanoniske beholdningen. Segmenter etter katalog og mal; et gjennomsnitt for hele nettstedet skjuler én problematisk seksjon. Verktøy: loggpipeline, crawler, søkemotor-dekningsrapporter, sitemap-eksporter og frigivelseskalender. Ferdig når: en signert diagnose navngir minst én målt begrensning eller avslutter sjekklisten som «ikke vesentlig», med dokumentasjon og en mer hensiktsmessig neste handling.

2. Bygg et pålitelig datasett med bot-forespørsler

Hva: opprett én normalisert forespørselstabell for analysevinduet. Hvorfor: brukeragentstrenger kan forfalskes, samplede analyseverktøy utelater botter, og CDN-logger kan avvike fra opprinnelseslogger. Loggfilanalyse innebærer å undersøke serverens tilgangsposter for å se hva crawlere faktisk har forespurt. Hvordan: kombiner CDN- og opprinnelsesdata der nødvendig, normaliser vert og URL-koding, fjern statiske ressurser med mindre rendring er i omfang, verifiser store søkebotter med leverandørens publiserte verifiseringsmetode, og behold status, byte, responstid og cache-utfall. Verktøy: CDN- eller nettserverlogger, DNS-verifisering, SQL eller en logganalysator. Ferdig når: datoområdet og oppbevaringen er dokumentert, kjente botter er skilt fra uverifiserte agenter, totaler stemmer overens med rådata, og den samme spørringen kan reprodusere alle diagrammer i diagnosen.

3. Mål hvor forespørsler blir sløst bort

Hva: klassifiser hver crawler-forespørsel som nyttig kanonisk, duplikat, omdirigert, feil, blokkert, parameter, fasett, internt søk, myk-404, ressurs eller ukjent. En myk 404 er en side som returnerer 200 OK, men oppfører seg som et manglende eller tomt resultat. Hvorfor: totalt crawl-volum kan ikke vise om crawlere oppdaterer lagerbeholdningen eller går i løkker gjennom verdiløse tilstander. Hvordan: koble forespørsler til crawl- og kanonisk-beholdning, grupper etter normalisert sti og parametersignatur, ranger deretter mønstre etter forespørselsantall og serverkostnad. Avstem disse mønstrene med dekningsårsaker som oppdaget men ikke indeksert, gjennomsøkt men ikke indeksert, duplikat, blokkert og myk 404; dekning forklarer søkemotorens rapporterte utfall, mens logger beviser forespørsler. Inspiser den ukjente gruppen manuelt i stedet for å tvinge den inn i en praktisk merkelapp. Verktøy: verifiserte logger, dekningsrapport, nettsted-crawler, kanonisk-eksport og responsprofiler. Ferdig når: minst 95 % av bot-forespørslene i omfang har en gjennomgått klassifisering, den gjenværende ukjente andelen er listet, og de største sløsingsmønstrene har eksempel-URL-er, dekningsutfall og eiere.

4. Begrens fasett- og parameter-URL-er ved kilden

Hva: styr filter-, sorterings-, paginerings-, sporings-, økt- og søkeparametere. Fasettert navigering lar brukere kombinere filtre som merke, farge og størrelse; ukontrollerte kombinasjoner kan skape et i praksis uendelig crawl-område. Hvorfor: å blokkere en crawler etter at maler har generert millioner av lenker behandler symptomet, mens oppdagelse, brukeratferd, analyse og andre botter forblir eksponert. Hvordan: tilordne hver parameter én funksjon og én retningslinje: indekserbar landingsside, kanonisk duplikat, noindex-side, omdirigering, avlenket tilstand eller blokkert mønster. Bruk stabil parameterrekkefølge, forhindre tomme og motstridende kombinasjoner, og fjern sporings- eller øktparametere fra interne lenker. Ikke gjør en side kanonisk til et mål med vesentlig forskjellig innhold bare for å undertrykke den. Verktøy: parameterregister, malfil, crawler med URL-mønsterrapporter, logger og automatiserte URL-tester. Ferdig når: hver observerte parameter har én godkjent retningslinje, gjennomsøkbare maler produserer kun tillatte kombinasjoner, forbudte kombinasjoner har testdekning, og loggvolumet for de målrettede mønstrene faller ved det avtalte kontrollpunktet.

5. Eliminer uendelige rom og crawl-feller

Hva: steng ruter som kan generere ubegrensede datoer, kalendere, paginering, ID-er, variantformer, sti-segmenter eller rekursive filtre. Hvorfor: en crawler kan fortsette å oppdage syntaktisk nye URL-er selv når hver side inneholder det samme tomme eller dupliserte resultatet. Hvordan: sett endelige grenser, returner 404 eller 410 for umulige tilstander, lenk kun til gyldige områder, normaliser regler for store/små bokstaver og etterfølgende skråstrek, omdiriger eksakte duplikater én gang, og slutt å generere «neste side»-lenker utover det siste resultatsettet. Test misdannede og ekstreme verdier, ikke bare solskinnshistorien. Verktøy: syntetisk URL-generator, crawler, logger, ruter-tester og kantregel-tester. Ferdig når: hver generator har dokumentert maksimum, tilstander utenfor område returnerer tiltenkt respons, ingen testet rute skaper en ny ubegrenset sekvens, og berørte forespørselsmønstre avtar uten å blokkere verdifulle sider.

6. Rett opp myke 404-er, feil og omdirigeringssløsing

Hva: få responskoder til å beskrive det faktiske utfallet. Hvorfor: en 200-tom side ber crawlere om å analysere og vurdere innhold som burde vært erklært manglende; gjentatte 5xx-svar bruker opp kapasitet og kan få en vert til å se upålitelig ut; kjeder bruker flere forespørsler på å nå én destinasjon. Hvordan: returner 404 for manglende URL-er, 410 for bevisst fjernede ressurser når det er hensiktsmessig, 200 kun for substansielle sider, og én enkelt omdirigering til den endelige kanoniske destinasjonen for flyttede URL-er. Reparer interne lenker som peker inn i omdirigeringer eller feil. Verktøy: logger, crawler, HTTP-testsuite, overvåking og ruteoversikt. Ferdig når: samplede tomme resultater returnerer ikke lenger 200, prioriterte ruter har ingen omdirigeringskjede, interne lenker løses direkte, og feilrateterskelen i beslutningsreglene passeres i to påfølgende målevinduer.

7. Sørg for konsistens i kanoniske- og indekskontroller

Hva: samkjøre respons, kanonisk URL , meta robots, HTTP-robots-hoder, interne lenker og sitemap-medlemskap. Hvorfor: motstridende signaler forårsaker gjentatte gjennomsøk: en URL kan være sendt inn i et sitemap, kanonisert et annet sted, lenket gjennom hele navigasjonen og blokkert fra direktivet som forklarer statusen. Hvordan: lag en regelmatrise for hver URL-klasse og test den produserte produksjonsresponsen. Bruk robots.txt for å administrere crawler-tilgang, ikke som en pålitelig fjerningsmekanisme; en blokkert URL kan ikke avsløre et noindex-direktiv på sidenivå for en crawler som aldri henter den. Verktøy: crawler, rå og rendret HTML, header-inspektør, robots-tester og URL-inspeksjon. Ferdig når: 100 % av prioriterte stikkprøver og alle mal-testcaser samsvarer med én sammenhengende regel, uten at noen indekserbar kanonisk URL er blokkert og intet ekskludert mønster promoteres via sitemaps eller primærnavigasjon.

8. Rens XML-sitemaps til en prioritetsfeed

Hva: publiser kun kanoniske, indekserbare 200-URL-er med sannferdige endringsdatoer i hvert XML-sitemap . Hvorfor: et sitemap er et oppdagelsessignal, ikke et arkiv over alle URL-er CMS-et har produsert. Omdirigeringer, duplikater, feil og uendrede lastmod-tidsstempler fortynner signalet og skjuler dekningssammenligninger. Hvordan: avstem sitemap-URL-er med den kanoniske beholdningen, del filer etter stabile diagnoseenheter som innholdstype eller katalog, fjern ekskluderte URL-er, og oppdater lastmod kun for substansielle sideendringer. Send inn endrede sitemaps og registrer nedlasting, advarsler og feil. Verktøy: sitemap-parser, CMS-eksport, logger og søkemotor-sitemap-rapporter. Ferdig når: hver innsendt URL returnerer 200, er selv-kanonisk og indekserbar, ekskluderinger er null, lastmod består en samplet innholdsendringssjekk, og innsendte teller samsvarer med den godkjente beholdningen.

9. Bruk interne lenker for å trekke prioriterte sider nærmere

Hva: reparer foreldreløse sider og reduser klikkavstanden til høyverdige URL-er gjennom nyttig intern lenking . Crawl-dybde er antall lenkesteg en crawler trenger for å nå en side fra en valgt startside. Hvorfor: å blokkere sløsing forteller ikke en crawler hva den skal besøke deretter; stabile HTML-lenker fra sterke, ofte besøkte sider gjør det. Hvordan: beregn dybde og innkommende lenker fra hjemmesiden og relevante knutepunkt, legg til kontekstuelle eller navigasjonslenker der brukere har nytte av det, erstatt lenker til omdirigerte URL-er, og sørg for at paginering eksponerer dypere lager. Ikke flat alt ut i en bunntekst. Verktøy: lenkegraf-crawler, maler, logger og søkeytelse etter katalog. Ferdig når: hver prioritert URL har minst én gjennomsøkbar innkommende lenke, ingen prioritert foreldreløs side gjenstår, avtalte prioriterte maler er innenfor tre lenkesteg fra et relevant knutepunkt, og logger bekrefter at nylig lenkede stikkprøver oppdages eller oppsøkes på nytt.

10. Beskytt vertskapasitet og rendringsstier

Hva: hold crawler-forespørsler raske og vellykkede uten å servere søkebotter en vesentlig annerledes side. Hvorfor: crawl-etterspørsel kan ikke kompensere for en vert som timeouter, rate-begrenser legitime crawlere uten forskjell, eller krever dyr rendring for grunnleggende innhold og lenker. Hvordan: sammenlign responstid og feil etter bot, rute, cache-status og mal; cache trygge responser; fjern dyre spørrestier; bevar essensielt HTML og lenker i den første responsen; og test brannmur- og CDN-regler med verifiserte botter. Verktøy: applikasjonsytelsesovervåking, CDN-analyse, logger, oppetidstester og rendret-side-inspeksjon. Ferdig når: verten møter avtalte respons- og feilterskler under forventet belastning, verifiserte crawlere blir ikke utilsiktet utfordret, og prioritert innhold pluss lenker er til stede uten brukerinteraksjon.

11. Rull ut etter mønster og verifiser avveiningen

Hva: frigjør det minste sammenhengende regelsettet, sammenlign deretter før og etter. Hvorfor: en global robots-, kanonisk-, rute- eller navigasjonsendring kan fjerne verdifulle langhale-sider raskere enn den fjerner sløsing. Hvordan: start med ett målbart URL-mønster eller én katalog, behold en kontroll der det er praktisk mulig, annoter frigivelsen, og sammenlign bot-forespørsler, feil, prioritert gjenoppsøkingsforsinkelse, dekning, visninger og serverlast etter en full crawl-syklus. Ha tilbakerullingsinstruksjoner ved siden av regelen. Verktøy: distribusjonslogg, serverlogger, dekningsrapporter, AmICited-rapporter og overvåking. Ferdig når: målverdien for målsøsingen forbedres, prioritert oppdagelse og indeksering ikke faller tilbake utover den erklærte toleransen, eieren signerer resultatet, og neste utrullings- eller tilbakerullingsbeslutning er registrert.

Verktøy i AmICited

AmICited leverer søkemotor- og ytelsesdokumentasjon rundt diagnosen. Rå serverlogger forblir den primære kilden for forespørselsnivåatferd på tvers av botter.

1. Åpne Bing Crawl på den levende Bing-crawl-rapporten for å gjennomgå Bings crawl-aktivitet og rapporterte URL-problemer. Registrer området, problemtype, eksempel-URL-er og eksporttidspunkt; generaliser ikke Bing-atferd til alle crawlere.

2. Bruk Sitemaps og indeksering på sitemap-rapporten for å sammenligne innsendte antall, siste nedlasting, advarsler og feil, sende inn et renset sitemap, eller be om indeksering for en avgrenset batch med endrede prioriterte URL-er. En forespørsel akselererer revurdering; den gjør ikke en blokkert eller lavkvalitets-side indekserbar.

3. Sjekk representative vinnere, sløsingsmønstre og reparerte sider i URL-inspeksjon på URL-inspeksjonsrapporten . Registrer den erklærte og valgte kanoniske, dekningsvurdering, siste gjennomsøking og inspeksjonstidspunkt. Dekningsvisningen er et voksende utvalg, ikke en fullstendig crawl-budsjett-rapport.

4. Åpne Google Search-kataloger på katalograpporten for å sammenligne klikk og visninger etter seksjon før du begrenser en katalog eller endrer dens lenker. En seksjon med lav trafikk kan fortsatt være strategisk nødvendig; bruk denne rapporten til å måle søkepåvirkning, ikke til å erklære crawl-sløsing alene.

Beslutningsregler: hvordan dårlig ser ut i tall

Dette er operasjonelle utløsere for denne sjekklisten, ikke universelle søkemotorgrenser. Erstatt dem kun med en dokumentert nettstedgrunnlinje og en godkjent risikotoleranse.

Ikke start et crawl-budsjett-prosjekt utelukkende fordi nettstedet krysser en rad med URL-antall. Motsatt, avvis ikke et nettsted med 20 000 sider hvis kalenderfelle genererer millioner av distinkte URL-er. Dokumentasjon på begrenset oppdagelse eller sløsing er den avgjørende faktoren.

Leveranse

Overlever en versjonert pakke, ikke et lysbilde som sier «crawl optimalisert»:

• crawl-budget-summary.md: omfang, beslutning, bot-verifiseringsmetode, analysevindu, funn, godkjente behandlinger, risikoer, frigivelsesrekkefølge og tilbakerullingsutløsere.
• crawl-pattern-register.csv: normalisert mønster, eksempel-URL, formål, forespørselsantall, andel, respons, kanonisk tilstand, sitemap-tilstand, innkommende lenker, forretningsverdi, behandling, eier og status.
• priority-url-sample.csv: minst 20 URL-er med grunnlinje- og kontrollpunktsfelter for oppdagelse, siste gjennomsøking, indeksvurdering, dybde, innkommende lenker, respons og valgt kanonisk.
• sitemap-reconciliation.csv: innsendt URL, lagerstatus, respons, kanonisk, indekserbarhet, lastmod-validering, handling og dokumentasjon.
• monitoring-spec.md: spørringer, dashbord, terskler, eiere, frekvens, varslingsruter, kontrollpunktsdatoer og oppbevaring.

Den tekniske SEO-ansvarlige eier pakken; utvikling signerer rute- og infrastrukturendringer; innholds- eller merchandising-eieren signerer enhver beslutning som fjerner en oppdagbar brukersti eller indekserbar landingsside.

Hva går galt

Teamet optimaliserer et bitte lite nettsted. Ingeniører bruker en sprint på å blokkere parametere mens viktige sider forblir tynne eller foreldreløse. Lukk sjekklisten som ikke vesentlig og omdiriger arbeidet til innhold, lenking eller indekserbarhet.

Robots.txt blir et fjerningsverktøy. Blokkerte URL-er kan forbli kjente, og crawlere kan ikke hente direktivene på sidenivå. Definer først den tiltenkte livssyklusen, fjern intern generering, og bruk respons-, omdirigerings-, kanonisk- eller noindex-atferden som matcher.

Hver fasett behandles som duplikat. En merke-og-kategori-kombinasjon med reell etterspørsel kan være en nyttig landingsside; en sorteringsrekkefølge er det som oftest ikke. Avgjør på mønsternivå ved hjelp av etterspørsel og innholdsmessig distinkthet.

En kanonisk tag forventes å stoppe gjennomsøking. Kanoniske tagger uttrykker en foretrukket versjon, men duplikater kan fortsatt hentes for å evaluere forholdet. Fjern sløsende lenker og generering i stedet for å stole på ett hint.

Sitemaps blir database-dumper. Omdirigerte, utgåtte, blokkerte og ikke-kanoniske URL-er skjuler beholdningen teamet faktisk ønsker gjennomsøkt. Avstem sitemap-medlemskap som en frigivelsesport.

Analyseverktøy forveksles med logger. Klientside-analyse registrerer sjelden søkebot-forespørsler. Uten verifiserte tilgangslogger kan teamet ikke måle forespørselsallokering eller responskostnad.

Utrullingen blokkerer inntektssider. En bred parameter- eller stiregel fanger opp gyldige kategorier, lokaliserte sider, paginering eller kampanjemål. Test positive og negative eksempler, trinnvis ett mønster, og behold en rask tilbakerulling.

Suksess betyr færre forespørsler. Crawl-volum kan falle fordi verdifulle sider forsvant fra oppdagelse. En vellykket endring reduserer sløsing samtidig som prioritert oppdagelse, indeksering og søkeetterspørsel forblir sunne.

Neste fase

Fôr mønsterregisteret, sitemap-avstemmingen, prioritetsutvalget og overvåkingstersklene inn i kontinuerlig oppdatering og iterering . Den fasen trenger stabile oppdagelsesstier og pålitelige endringssignaler; ellers kan en oppdatert side publiseres korrekt, men forbli usynlig bak crawl-feller eller svake interne lenker.

Gjenåpne denne sjekklisten etter en migrering, plattform- eller ruteendring, utgivelse av fasettert navigering, større lagerutvidelse, vedvarende feilhendelse eller et avtalt terskelbrudd. Ikke kjør hele øvelsen på nytt på en kalenderbasis når overvåkingsgrunnlinjen forblir ren.

FAQ

FAQ-en nedenfor dekker omfang, robots-regler, parametere, sitemaps og gjennomgangsfrekvens. Det styrende prinsippet er konsistent: klassifiser URL-rommet først, bruk forespørselsdokumentasjon som neste steg, og endre crawler-kontroller bare når det tiltenkte bruker- og indekseringsutfallet er eksplisitt.