Stora e-handlar, marknadsplatser, kataloger och publicistsajter kan skapa fler URL:er än sökmotorerna hinner eller behöver prioritera. Då handlar teknisk SEO inte bara om att göra webbplatsen möjlig att crawla, utan om att styra crawlningen mot de sidor som har verkligt användar- och affärsvärde.
Vi på TribuSoft hjälper företag att analysera URL-lager, serverloggar och Google Search Console. Därefter prioriterar vi åtgärder som minskar onödig crawlning, stärker förutsättningarna för viktiga sidor och fungerar i er webbplattform och driftmiljö.
Crawl budget är den mängd URL:er som Google kan och vill crawla på en webbplats. Det är inte en fast daglig kvot som visas i Search Console och går inte att räkna fram med en enkel formel.
Begreppet består i praktiken av två delar. Crawl capacity limit är hur mycket Googlebot kan hämta utan att överbelasta servern. Crawl demand är hur mycket Google vill crawla, bland annat utifrån URL:ernas popularitet, aktualitet och signaler om användarvärde.
Crawling, indexering och ranking är olika saker. En crawlad URL blir inte automatiskt indexerad, och mer crawlning ger inte i sig bättre placeringar. Målet är i stället att en större andel av sökmotorernas förfrågningar träffar relevanta, aktuella och prioriterade URL:er.
De flesta mindre och stabila webbplatser behöver inget separat crawl budget-projekt. Om nya och uppdaterade sidor crawlas inom rimlig tid finns det ofta större SEO-frågor att prioritera först.
Crawl budget blir mer relevant när URL-inventariet är stort, förändras snabbt eller kan växa okontrollerat. Google pekar bland annat på webbplatser med omkring en miljon unika sidor, webbplatser med minst cirka 10 000 unika sidor som ändras dagligen och webbplatser där många URL:er är upptäckta men ännu inte indexerade. Riktmärkena är ungefärliga, inte fasta gränser.
En mindre webbplats kan också få ett crawlproblem om filter, kalendrar, intern sökfunktion eller parametrar skapar ett nästan obegränsat antal URL-varianter. Omvänt kan en större webbplats fungera väl när URL-lagret är disciplinerat och infrastrukturen är stabil.
Statusen ”Discovered – currently not indexed” är en signal att undersöka, men den bevisar inte ensam att crawl budget är grundorsaken. Låg efterfrågan, duplicering, svag intern exponering eller innehåll med begränsat värde kan också påverka utfallet.
Vi börjar därför med en triage: begränsas webbplatsen av serverkapacitet, låg crawl demand, onödiga URL-lager eller ett separat indexeringsproblem? Den avgränsningen minskar risken för kostsamma åtgärder som inte löser den faktiska flaskhalsen.
Google Search Console ger en bra överblick genom Crawl Stats-rapporten. Där kan ni följa antal förfrågningar, nedladdad datamängd, genomsnittlig svarstid samt fördelning efter svarskod, filtyp, crawländamål och Googlebot-typ. Host status hjälper också till att upptäcka tillgänglighetsproblem.
Men Crawl Stats är aggregerad. För att se vilka URL:er Googlebot faktiskt har begärt behöver stora webbplatser normalt analysera råa serverloggar. Loggarna visar verkliga förfrågningar, svarstider, statuskoder och tidpunkter på URL-nivå.
Bottrafiken måste verifieras. En user-agent går att förfalska, så en seriös logganalys validerar att förfrågningarna kommer från Googlebot innan data används i prioriteringen.
Ett stort URL-inventarium behöver en tydlig ägare och ett definierat syfte för varje URL-typ. Vår bedömning är att crawl budget inte löses genom en enskild inställning. Den förbättras när URL-lager, duplicering, serverkapacitet och prioritering behandlas som samma verksamhetsfråga.
Vi delar vanligtvis in URL:er efter affärsvärde och önskat tekniskt tillstånd. Det gör det lättare för SEO, utveckling, produkt och drift att förstå vilka förändringar som ska prioriteras.
För varje segment bör ni dokumentera källa, volym, intern exponering, observerad botaktivitet, önskat tillstånd, åtgärdsägare och uppföljningsmått. En produktägare kan exempelvis äga filterlogiken, utveckling implementerar förändringen och SEO följer utfallet i loggar och Search Console.
Automatiserad och AI-baserad analys kan snabba upp klassificering, mönsterigenkänning och avvikelselarm i stora datamängder. Beslut om att blockera, konsolidera eller förändra en URL-typ måste däremot granskas av människor som förstår både affären och den tekniska lösningen.
Crawl waste uppstår när en stor del av botaktiviteten går till URL:er som inte behöver prioriteras för organisk synlighet eller som saknar eget innehållsvärde. På stora webbplatser är det ofta summan av många små URL-mönster, snarare än en enskild felaktig sida, som skapar problemet.
Facetterad navigering är ett vanligt exempel. Filter för storlek, färg, varumärke, pris och lagerstatus kan tillsammans skapa ett mycket stort antal kombinationer. Vissa kombinationer kan ha tydlig sök- och affärsefterfrågan, medan andra bara ger tunna, dubblerade eller tomma resultatsidor. De ska därför inte hanteras med en generell massregel.
Vi granskar också sorteringar, interna sökresultat, sessions-ID:n, spårningsparametrar, kalender-URL:er och flera sökvägar till samma innehåll. Inkonsekvent parameterordning kan exempelvis skapa olika URL:er för samma urval. Tomma filterkombinationer bör inte presenteras som vanliga innehållssidor med 200-svar.
Duplicerade URL:er kan uppstå genom parametrar, versaler och gemener, olika filtreringsvägar, protokoll, internlänkar eller system som skapar alternativa adresser. Konsolidering gör URL-inventariet tydligare för både användare och sökmotorer. Canonical-signaler kan vara en del av arbetet, men de är inte ett direkt stopp för crawlning och kan inte ersätta en genomtänkt URL-struktur.
Målet är inte att stänga allt som inte ska ranka. Målet är att minska onödig variation och säkerställa att prioriterade URL:er är konsekventa, lättillgängliga och aktuella.
Crawl capacity påverkas av hur väl webbplatsen svarar när Googlebot begär innehåll. Återkommande 5xx-fel, anslutningstimeouts och långsamma svar kan tyda på kapacitets- eller tillgänglighetsproblem. Google kan då minska crawlningen för att undvika att belasta webbplatsen ytterligare.
Arbetet handlar därför om mer än sidans laddningsupplevelse. Vi granskar mönster i svarstider, host status, fel och belastning per URL-typ. En produktfeed, intern sökning eller tung filtrering kan exempelvis belasta origin-servern på ett annat sätt än vanliga kategorisidor.
Cache, CDN och stabila resurs-URL:er kan minska onödiga förfrågningar och avlasta servern. Oförändrade resurser bör inte få nya adresser i onödan genom cache-busting. HTTP 304 för oförändrat innehåll kan också spara serverresurser. Samtidigt löser inte större serverkapacitet ensam ett URL-lager med lågkvalitativa eller obegränsade varianter.
Rätt åtgärd beror på om URL:en ska vara användbar för besökaren, möjlig att crawla, indexerbar eller helt borttagen. Robots.txt, noindex, canonical, korrekta statuskoder och konsolidering fyller olika funktioner och ska inte användas som utbytbara lösningar.
Vi börjar med avsikten och granskar sedan implementationen i den aktuella plattformen. Särskilt för filter och parametrar behöver vi kontrollera konsekvenser för användarupplevelse, intern sökning, analys och andra marknader innan en förändring rullas ut.
En crawl budget-förändring bör utgå från en dokumenterad baslinje och följas upp över tid. Det finns ingen universell målnivå för antal crawls eller en bestämd väntetid innan utfallet kan bedömas. Utvärderingen behöver ta hänsyn till webbplatsens storlek, förändringstakt och säsong.
Vi jämför därför prioriterade URL-segment med faktisk botaktivitet före och efter en release. Vi letar efter om Googlebot når viktiga nya eller uppdaterade sidor i rimligare takt, om lågprioriterade URL-lager tar mindre plats och om serverhälsan är stabil. Att minska en typ av crawlning innebär dock inte automatiskt att exakt samma resurser flyttas till andra URL:er.
Crawl budget-arbete blir ofta ett samordningsprojekt. SEO-teamet ser problemet i data, men förändringen kan behöva göras i e-handelsplattformen, CMS:et, sökfunktionen, produktkatalogen, CDN-konfigurationen eller servermiljön.
För större organisationer arbetar vi med tydliga hypoteser, tekniska krav, ägare, teststeg och övervakning efter release. Det minskar risken att en förbättring för SEO försämrar filterupplevelsen, intern sökning, analysdata eller driftstabilitet.
Crawl budget är därför en viktig del av Enterprise SEO för stora organisationer. Särskilt när många team, marknader, subdomäner, mallar och system ska fungera tillsammans över tid.
Hos oss på TribuSoft kombinerar vi teknisk SEO med webbutveckling, serverdrift och mätning. Vi går från observation till genomförbar åtgärdsplan, i stället för att lämna över en generell checklista.
Arbetet kan omfatta URL-inventering, analys av Search Console och verifierade serverloggar, segmentering av botaktivitet, bedömning av filter och parametrar samt granskning av svarstider och serverfel. Vi prioriterar sedan förändringar utifrån affärsvärde, teknisk risk och förväntad påverkan på crawlningens effektivitet.
Vid behov hjälper vi också till i implementationen och följer upp effekten efter lansering. Det passar företag med stora e-handlar, kataloger, publicistmiljöer eller komplexa plattformar där SEO behöver samspela med utveckling och drift. Läs mer om Teknisk SEO för crawlning, indexering och prestanda.
Crawl budget är den mängd URL:er som Google kan och vill crawla på en webbplats. Den påverkas både av webbplatsens tekniska kapacitet och av hur stort intresse Google har av att återkomma till olika URL:er.
Nej. Ämnet är främst relevant för mycket stora, snabbt föränderliga eller tekniskt komplexa webbplatser. Mindre och stabila sajter behöver sällan ett separat crawl budget-projekt om nya och uppdaterade sidor crawlas inom rimlig tid.
Inte direkt. Crawling, indexering och ranking är olika processer. Effektivare crawlning kan bidra till att viktiga nya eller uppdaterade sidor bearbetas snabbare, men det garanterar varken indexering eller högre placeringar.
Crawl Stats ger en värdefull överblick över Googlebots aktivitet, svarstider och fel. Serverloggar behövs när ni vill se exakt vilka URL:er boten faktiskt har begärt och hur crawlningen fördelas mellan olika URL-segment.
Nej. Statusen kan vara en signal om att crawlningen behöver utredas, men även duplicering, svag upptäckt, låg efterfrågan och innehållskvalitet kan bidra. En korrekt diagnos kräver analys av URL-segment och faktisk botaktivitet.
Nej. Google behöver först crawla sidan för att kunna läsa noindex-direktivet. Noindex är därför främst ett verktyg för indexeringskontroll, inte ett direkt sätt att stoppa crawlning.
Robots.txt kan hindra Googlebot från att hämta en URL, men det är inte en generell metod för att ta bort den från sökresultatet. Valet av kontrollmekanism måste utgå från URL:ens syfte och önskat tillstånd.
Återkommande 5xx-fel och timeouts kan signalera kapacitets- eller tillgänglighetsproblem. Då kan Google minska crawlningen för att undvika att överbelasta webbplatsen. Snabb och stabil infrastruktur är därför en viktig del av arbetet.
Om Googlebot lägger tid på fel URL:er, viktiga sidor upptäcks långsamt eller serverproblem påverkar crawlningen kan vi hjälpa er att hitta orsaken och prioritera rätt åtgärder.
Få en kostnadsfri offert eller inled en dialog med oss om hur vi kan stärka er tekniska SEO, webbplattform och organiska tillväxt.
