Checklista för hantering av crawl-budget

Crawl-budget är den praktiska gränsen för hur mycket genomsökning en sökmotor är villig och kan göra på en webbplats över tid. Att hantera det innebär att minska förfrågningar som inte kan förbättra upptäckt eller indexering, och sedan göra viktiga webbadresser lättare att hitta och billigare att hämta.

Checklista: hantering av crawl-budget. Tidsram: 1–2 arbetsdagar för diagnos, därefter 1–3 utvecklingssprintar för godkända åtgärder. Ägare: teknisk SEO-ansvarig. Medverkande: plattformsingenjör, CDN- eller infrastrukturägare, analysingenjör samt merchandising- eller innehållsägare för berört URL-utrymme. Releasebehörighet: teknisk SEO-ansvarig och utvecklingsägare gemensamt.

Var tydlig med omfattningen: en frisk webbplats med 2 000 eller 8 000 kanoniska sidor har nästan aldrig ett crawl-budget-projekt. Den har ett prioriterings-, länknings-, kvalitets- eller indexerbarhetsproblem. Starta denna checklista när en stor eller snabbföränderlig webbplats har bevis på crawler-slöseri, försenad upptäckt, upprepad genomsökning av lågvärdes-URL:er eller belastning på värden – inte för att en crawlerrapport innehåller ett stort antal.

Varför denna fas, och varför här

Även om detta är en fristående checklista snarare än en numrerad fas, förbrukar den den tekniska baslinje-revisionen : kanoniska regler, statuskodsresultat, renderingsbeteende, webbplatsarkitektur, sitemap-inventering och indexäckning. Den behöver också en godkänd innehållsinventering, eftersom “slöseri” inte kan definieras förrän verksamheten har sagt vilka webbadresser som ska hittas, uppdateras och indexeras.

Kör den efter att teamet kan skilja värdefulla kanoniska sidor från filter, dubbletter, utgånget lager, intern sökning och administrativa vägar. Att köra den tidigare uppmuntrar till generell blockering. Att köra den efter en stor programmatisk lansering, migrering eller release av fasetterad navigering är för sent: crawlers kan redan vara fångade i ett i praktiken obegränsat URL-utrymme.

Om den hoppas över på en genuint stor webbplats kan nya och ändrade prioriterade webbadresser vänta bakom oändliga parameterkombinationer, felsidor, omdirigeringskedjor och dubbletter. Om den körs på en liten frisk webbplats förbrukar den utvecklingstid utan att adressera den verkliga begränsningen. Argumentet om beroenden är enkelt: klassificering kommer före kontroll, och bevis kommer före regler.

Indata och utdata

Resultaten är överenskommelsen med utveckling och nästa mätcykel. “Förbättra crawl-effektivitet” är inte en leverans.

Checklistan

Notera PASS, FAIL eller N/A och bifoga bevis för varje punkt. Varje punkt är klar först när dess “Klar när”-villkor kan observeras.

1. Bevisa att crawl-budget är begränsningen

Vad: avgör om detta arbete förtjänar ett projekt. Varför: crawl-budget får ofta skulden när en sida egentligen är av låg kvalitet, föräldralös, icke-kanonisk, blockerad eller avsiktligt exkluderad. Hur: jämför antal kanoniska webbadresser, dagligt skapande av webbadresser, serverhälsa, datum för senaste genomsökning, upptäcktsfördröjning, täckningsorsaker och andelen verifierade botförfrågningar som spenderas utanför den kanoniska inventeringen. Segmentera per katalog och mall; ett webbplatsövergripande genomsnitt döljer en okontrollerad sektion. Verktyg: loggpipeline, crawler, sökmotorers täckningsrapporter, sitemap-export och releasekalender. Klar när: en signerad diagnos namnger minst en uppmätt begränsning eller avslutar checklistan som “inte väsentlig”, med bevis och en mer lämplig nästa åtgärd.

2. Bygg en tillförlitlig datauppsättning för botförfrågningar

Vad: skapa en normaliserad förfrågningstabell för analysfönstret. Varför: användaragentsträngar kan förfalskas, samplad analys utelämnar botar och CDN-loggar kan skilja sig från ursprungsloggar. Loggfilanalys innebär att granska serveråtkomstposter för att se vad crawlers faktiskt begärde. Hur: kombinera CDN- och ursprungsdata vid behov, normalisera värd och URL-kodning, ta bort statiska tillgångar om inte rendering är inom scope, verifiera större sökbotar med leverantörens publicerade verifieringsmetod, och behåll status, byte, svarstid och cache-utfall. Verktyg: CDN- eller webbserverloggar, DNS-verifiering, SQL eller en logganalysator. Klar när: datumintervall och lagring är dokumenterade, kända botar är separerade från overifierade agenter, totaler stämmer överens med rådata, och samma fråga kan återskapa varje diagram i diagnosen.

3. Mät var förfrågningar går till spillo

Vad: klassificera varje crawlerförfrågan som användbar kanonisk, dubblett, omdirigering, fel, blockerad, parameter, faset, intern sökning, mjuk 404, tillgång eller okänd. En mjuk 404 är en sida som returnerar 200 OK men beter sig som ett saknat eller tomt resultat. Varför: total crawlvolym kan inte visa om crawlers uppdaterar lager eller loopar genom värdelösa tillstånd. Hur: koppla förfrågningar till crawl- och kanonisk inventering, gruppera efter normaliserad sökväg och parametersignatur, rangordna sedan mönster efter antal förfrågningar och serverkostnad. Stäm av dessa mönster med täckningsorsaker som upptäckt men inte indexerad, genomsökt men inte indexerad, dubblett, blockerad och mjuk 404; täckning förklarar en sökmotors rapporterade utfall, medan loggar bevisar förfrågningar. Inspektera den okända gruppen manuellt istället för att tvinga in den i en bekväm etikett. Verktyg: verifierade loggar, täckningsexport, webbplats-crawler, kanonisk export och svarsprofilering. Klar när: minst 95 % av aktuella botförfrågningar har en granskad klassificering, den återstående okända delen är listad, och de främsta slöserimönstren har exempel-URL:er, täckningsutfall och ägare.

4. Begränsa fasetter och parametrar vid källan

Vad: styr filter-, sorterings-, paginerings-, spårnings-, sessions- och sökparametrar. Fasetterad navigering låter användare kombinera filter som märke, färg och storlek; okontrollerade kombinationer kan skapa ett i praktiken oändligt crawl-utrymme. Varför: att blockera en crawler efter att mallar genererat miljoner länkar behandlar symptomet medan upptäckt, användarbeteende, analys och andra botar förblir exponerade. Hur: tilldela varje parameter en funktion och en policy: indexerbar målsida, kanonisk dubblett, noindex-sida, omdirigering, olänkat tillstånd eller blockerat mönster. Använd stabil parameterordning, förhindra tomma och motsägelsefulla kombinationer och ta bort spårnings- eller sessionsparametrar från interna länkar. Kanonisera inte en sida till ett mål med väsentligt annorlunda innehåll enbart för att undertrycka den. Verktyg: parameterregister, mallkälla, crawler med URL-mönsterrapporter, loggar och automatiserade URL-tester. Klar när: varje observerad parameter har en godkänd policy, crawlbara mallar avger endast tillåtna kombinationer, förbjudna kombinationer har testtäckning, och loggvolymen för de riktade mönstren sjunker vid den överenskomna kontrollpunkten.

5. Eliminera oändliga utrymmen och crawlfällor

Vad: stäng vägar som kan generera obegränsade datum, kalendrar, paginering, ID:n, skiftlägesvarianter, sökvägssegment eller rekursiva filter. Varför: en crawler kan fortsätta upptäcka syntaktiskt nya webbadresser även när varje sida innehåller samma tomma eller duplicerade resultat. Hur: sätt ändliga gränser, returnera 404 eller 410 för omöjliga tillstånd, länka endast till giltiga intervall, normalisera regler för skiftläge och avslutande snedstreck, omdirigera exakta dubbletter en gång och sluta generera nästa-sida-länkar bortom den slutliga resultatuppsättningen. Testa felaktiga och extrema värden, inte bara lyckade scenarier. Verktyg: syntetisk URL-generator, crawler, loggar, routertester och kantregeltester. Klar när: varje generator har ett dokumenterat maximum, tillstånd utanför intervallet returnerar det avsedda svaret, ingen testad väg skapar en ny obegränsad sekvens, och berörda förfrågningsmönster minskar utan att värdefulla sidor blockeras.

6. Korrigera mjuka 404:or, fel och omdirigeringsslöseri

Vad: få svarskoder att beskriva det faktiska utfallet. Varför: en 200-tom sida ber crawlers att tolka och bedöma innehåll som borde ha förklarats saknat; upprepade 5xx-svar förbrukar kapacitet och kan få en värd att se opålitlig ut; kedjor använder flera förfrågningar för att nå en destination. Hur: returnera 404 för saknade webbadresser, 410 för avsiktligt borttagna resurser när lämpligt, 200 endast för substantiella sidor och en enda omdirigering till den slutliga kanoniska destinationen för flyttade webbadresser. Reparera interna länkar som pekar in i omdirigeringar eller fel. Verktyg: loggar, crawler, HTTP-testpaket, övervakning och ruttinventering. Klar när: samplade tomma resultat inte längre returnerar 200, prioriterade vägar har ingen omdirigeringskedja, interna länkar löser direkt, och feltröskeln i beslutsreglerna passeras för två på varandra följande mätfönster.

7. Gör kanoniska- och indexkontroller konsekventa

Vad: justera svar, kanonisk webbadress , meta robots, HTTP-robots-huvuden, interna länkar och sitemap-medlemskap. Varför: motstridiga signaler orsakar upprepade återbesök: en webbadress kan vara inskickad i en sitemap, kanoniserad någon annanstans, länkad genom hela navigeringen och blockerad från direktivet som förklarar dess status. Hur: skapa en regelmatris för varje URL-klass och testa det renderade produktionssvaret. Använd robots.txt för att hantera crawleråtkomst, inte som en tillförlitlig borttagningsmekanism; en blockerad webbadress kan inte avslöja ett noindex-direktiv på sidnivå för en crawler som aldrig hämtar den. Verktyg: crawler, rå och renderad HTML, huvudinspektör, robots-testare och URL-inspektion. Klar när: 100 % av prioriterade prover och alla malltestfall matchar en sammanhängande regel, utan att någon indexerbar kanonisk webbadress är blockerad och inget exkluderat mönster främjas via sitemaps eller primär navigering.

8. Rensa XML-sitemaps till ett prioriterat flöde

Vad: publicera endast kanoniska, indexerbara 200-webbadresser och sanningsenliga ändringsdatum i varje XML-sitemap . Varför: en sitemap är en upptäcktssignal, inte ett arkiv över varje webbadress som CMS:et producerat. Omdirigeringar, dubbletter, fel och oförändrade lastmod-tidsstämplar försvagar den signalen och försvårar täckningsjämförelser. Hur: stäm av sitemap-URL:er mot den kanoniska inventeringen, dela upp filer efter stabila diagnostiska enheter som innehållstyp eller katalog, ta bort exkluderade webbadresser och uppdatera lastmod endast för substantiella sidförändringar. Skicka in ändrade sitemaps och registrera nedladdning, varningar och fel. Verktyg: sitemap-tolk, CMS-export, loggar och sökmotorers sitemap-rapporter. Klar när: varje inskickad webbadress returnerar 200, är självkanonisk och indexerbar, exkluderingar är noll, lastmod klarar en samplad kontroll av innehållsändringar och inskickade antal stämmer överens med den godkända inventeringen.

9. Använd interna länkar för att dra prioriterade sidor närmare

Vad: reparera föräldralösa sidor och minska klickavståndet till högvärdes-URL:er genom användbar intern länkning . Crawl-djup är antalet länksteg en crawler behöver för att nå en sida från en vald startsida. Varför: att blockera slöseri säger inte till en crawler vad den ska besöka härnäst; stabila HTML-länkar från starka, ofta besökta sidor gör det. Hur: beräkna djup och inlänkar från startsidan och relevanta nav, lägg till kontextuella eller navigationslänkar där användare gynnas, ersätt länkar till omdirigerade webbadresser och säkerställ att paginering exponerar djupare lager. Platta inte ut allt i en sidfot. Verktyg: länkgraf-crawler, mallar, loggar och sökprestanda per katalog. Klar när: varje prioriterad webbadress har minst en crawlagbar inlänk, inga prioriterade föräldralösa sidor finns kvar, överenskomna prioriterade mallar är inom tre länksteg från ett relevant nav, och loggar bekräftar att nyligen länkade prover upptäcks eller återbesöks.

10. Skydda värdkapacitet och renderingsvägar

Vad: håll crawlerförfrågningar snabba och framgångsrika utan att servera sökbotar en väsentligt annorlunda sida. Varför: crawl-efterfrågan kan inte kompensera för en värd som time-outar, rate-begränsar legitima crawlers urskillningslöst eller kräver dyr rendering för grundläggande innehåll och länkar. Hur: jämför svarstid och fel per bot, väg, cachestatus och mall; cachelagra säkra svar; ta bort dyra frågesökvägar; bevara väsentlig HTML och länkar i det initiala svaret; och testa brandväggs- och CDN-regler med verifierade botar. Verktyg: applikationsprestandaövervakning, CDN-analys, loggar, drifttidstester och renderad sidinspektion. Klar när: värden uppfyller överenskomna svars- och feltrösklar under förväntad belastning, verifierade crawlers utmanas inte av misstag, och prioriterat innehåll plus länkar finns utan en användarinteraktion.

11. Rulla ut per mönster och verifiera avvägningen

Vad: släpp den minsta sammanhängande regeluppsättningen, jämför sedan före och efter. Varför: en global robots-, kanonisk-, routing- eller navigationsändring kan ta bort värdefulla långsvanssidor snabbare än den tar bort slöseri. Hur: börja med ett mätbart URL-mönster eller en katalog, bevara en kontroll där praktiskt, annotera releasen och jämför botförfrågningar, fel, prioriterad omsökningsfördröjning, täckning, visningar och serverbelastning efter en fullständig crawlcykel. Förvara återställningsinstruktioner bredvid regeln. Verktyg: distributionslogg, serverloggar, täckningsrapporter, AmICited-rapporter och övervakning. Klar när: måttet för målslöseri förbättras, prioriterad upptäckt och indexering inte försämras bortom den deklarerade toleransen, ägaren signerar resultatet och nästa beslut om utrullning eller återställning dokumenteras.

Verktyg i AmICited

AmICited tillhandahåller sökmotor- och prestandabevis kring diagnosen. Råa serverloggar förblir den sanna källan för förfrågningsbeteende över botar.

1. Öppna Bing Crawl på den live Bing-crawl-rapporten för att granska Bings crawlaktivitet och rapporterade URL-problem. Fånga intervallet, problemtypen, exempel-URL:er och exporttiden; generalisera inte Bing-beteende till varje crawler.

2. Använd Sitemaps och indexering på sitemap-rapporten för att jämföra inskickade antal, senaste nedladdning, varningar och fel, skicka in en rensad sitemap eller begär indexering för en avgränsad batch med ändrade prioriterade webbadresser. En begäran påskyndar omprövning; den gör inte en blockerad eller lågkvalitativ sida indexerbar.

3. Kontrollera representativa vinnare, slöserimönster och reparerade sidor i URL-inspektion på URL-inspektionsrapporten . Registrera den deklarerade och valda kanoniska, täckningsutlåtande, senaste genomsökning och inspektionstid. Dess täckningsvy är ett växande sampel, inte en fullständig crawl-budget-rapport.

4. Öppna Google Search-kataloger på katalograpporten för att jämföra klick och visningar per sektion innan du begränsar en katalog eller ändrar dess länkar. En sektion med låg trafik kan fortfarande vara strategiskt nödvändig; använd denna rapport för att bedöma sökpåverkan, inte för att förklara crawl-slöseri i sig.

Beslutsregler: hur dåligt ser ut i siffror

Dessa är operativa utlösare för denna checklista, inte universella sökmotorgränser. Ersätt dem endast med en dokumenterad webbplatsbaslinje och en godkänd risktolerans.

Öppna inte ett crawl-budget-projekt enbart för att webbplatsen passerar en rad för antal webbadresser. Å andra sidan, avfärda inte en webbplats med 20 000 sidor vars kalenderfälla genererar miljontals distinkta webbadresser. Bevis på begränsad upptäckt eller slöseri är den avgörande faktorn.

Leverans

Lämna över ett versionshanterat paket, inte en bild som säger “crawl optimerad”:

• crawl-budget-summary.md: omfattning, beslut, botverifieringsmetod, analysfönster, resultat, godkända behandlingar, risker, lanseringsordning och återställningsutlösare.
• crawl-pattern-register.csv: normaliserat mönster, exempel-URL, syfte, antal förfrågningar, andel, svar, kanonisk status, sitemap-status, inlänkar, affärsvärde, behandling, ägare och status.
• priority-url-sample.csv: minst 20 webbadresser med baslinje- och kontrollpunktsfält för upptäckt, senaste genomsökning, indexutlåtande, djup, inlänkar, svar och vald kanonisk.
• sitemap-reconciliation.csv: inskickad webbadress, lagerstatus, svar, kanonisk, indexerbarhet, lastmod-validering, åtgärd och bevis.
• monitoring-spec.md: frågor, dashboardar, trösklar, ägare, kadens, larmvägar, kontrollpunktsdatum och lagring.

Den tekniska SEO-ansvarige äger paketet; utveckling signerar väg- och infrastrukturändringar; innehålls- eller merchandising-ägaren signerar varje beslut som tar bort en upptäckbar användarväg eller indexerbar målsida.

Vad kan gå fel

Teamet optimerar en liten webbplats. Ingenjörer spenderar en sprint på att blockera parametrar medan viktiga sidor förblir tunna eller föräldralösa. Avsluta checklistan som inte väsentlig och omdirigera arbetet till innehåll, länkning eller indexerbarhet.

Robots.txt blir ett borttagningsverktyg. Blockerade webbadresser kan förbli kända, och crawlers kan inte hämta deras direktiv på sidnivå. Definiera den avsedda livscykeln först, ta bort intern generering och använd svar, omdirigering, kanonisk eller noindex-beteende som matchar den.

Varje faset behandlas som dubblett. En kombination av märke och kategori med verklig efterfrågan kan vara en användbar målsida; en sorteringsordning är det oftast inte. Beslut på mönsternivå med hjälp av efterfrågan och innehållsdistinkthet.

En kanonisk-tagg förväntas stoppa genomsökning. Kanoniska uttrycker en föredragen version, men dubbletter kan fortfarande hämtas för att utvärdera relationen. Ta bort slösaktiga länkar och generering snarare än att förlita sig på en ledtråd.

Sitemaps blir databasdumpar. Omdirigerade, utgångna, blockerade och icke-kanoniska webbadresser fördunklar inventeringen som teamet faktiskt vill ska genomsökas. Stäm av sitemap-medlemskap som en release-grind.

Analys misstas för loggar. Klientbaserad analys registrerar sällan sökbotförfrågningar. Utan verifierade åtkomstloggar kan teamet inte mäta förfrågningsallokering eller svarskostnad.

Utrullningen blockerar intäktssidor. En bred parameter- eller sökvägsregel fångar giltiga kategorier, lokaliserade sidor, paginering eller kampanjmål. Testa positiva och negativa exempel, stega ett mönster i taget och ha en snabb återställning redo.

Framgång innebär färre förfrågningar. Crawlvolym kan sjunka för att värdefulla sidor försvann från upptäckt. En framgångsrik förändring minskar slöseri medan prioriterad upptäckt, indexering och sökefterfrågan förblir hälsosamma.

Nästa fas

Mata mönsterregistret, sitemap-avstämningen, prioriterat urval och övervakningströsklar till kontinuerlig uppdatering och iteration . Den fasen behöver stabila upptäcktsvägar och pålitliga förändringssignaler; annars kan en uppdaterad sida publiceras korrekt men ändå vänta osynlig bakom crawlfällor eller svaga interna länkar.

Öppna denna checklista igen efter en migrering, plattforms- eller routingförändring, release av fasetterad navigering, större lagerutökning, ihållande felincident eller ett överskridet överenskommet tröskelvärde. Kör inte om hela övningen på en kalender när övervakningsbaslinjen fortfarande är ren.

FAQ

FAQ nedan täcker omfattning, robots-regler, parametrar, sitemaps och granskningsintervall. Den styrande principen är konsekvent: klassificera URL-utrymmet först, använd förfrågningsbevis därefter och ändra crawlerkontroller endast när det avsedda användar- och indexeringsutfallet är explicit.