Versteckte Features in der Google Search Console<\/a><\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\nPurpose: Warum Google \u00fcberhaupt anklopft<\/h2>\n\n\n\n
Die Purpose-Dimension beantwortet nicht \u201ewelche URL\u201c, sondern \u201ewelche Absicht hatte der Crawl\u201c. <\/p>\n\n\n\n
Discovery vs. Refresh<\/h3>\n\n\n\n
In der Praxis wird Purpose h\u00e4ufig so verstanden: <\/p>\n\n\n\n
Discovery<\/strong> steht f\u00fcr Crawls, bei denen Google neue, noch nicht bekannte, URLs entdecken will.
Wenn Discovery hoch ist, dann hat Google viel Neues gefunden \u2013<\/p>\n\n\n\noder auch viel neuen M\u00fcll gefunden. Sowas wie Parameter-URLs, Facetten, Session-IDs, interne Suchseiten.<\/sup><\/p>\n\n\n\nRefresh<\/strong> ist das Wieder-Crawlen bereits bekannter URLs, um \u00c4nderungen mitzunehmen.
Wenn Refresh hoch ist, crawlt Google vor allem Bestand \u2013 was sowohl gut sein kann, als auch schlecht.
Gut: Wichtige Seiten werden frisch gehalten.
Schlecht: Google verschwendet Zeit auf redundante Seiten<\/p>\n\n\n\nWas Purpose euch verr\u00e4t<\/h3>\n\n\n\n\n- Hoher Discovery-Anteil<\/strong>: H\u00e4ufig ein Signal f\u00fcr URL-Explosion, also dass Google versucht, euer gesamtes bekanntes URL-Inventar abzugrasen \u2013 inklusive Duplikaten. <\/li>\n\n\n\n
- Hoher Refresh-Anteil<\/strong>: Entweder eure Inhalte sind relevant und \u00e4ndern sich oft, oder ihr produziert st\u00e4ndig kleine \u00c4nderungen an vielen URLs und der Googlebot spielt \u201eUnd t\u00e4glich gr\u00fc\u00dft das Murmeltier\u201c.<\/li>\n\n\n\n
- Purpose-Spr\u00fcnge nach Relaunch\/Migration<\/strong>: Site-weite Events wie Site Moves k\u00f6nnen Crawl Demand erh\u00f6hen, weil Google neu verarbeiten will.<\/li>\n<\/ul>\n\n\n\n
Dateitypen: Wof\u00fcr ihr Crawl Budget verballert <\/h2>\n\n\n\n
Die File-Type-Dimension zeigt, welche Dateitypen Google beim Crawlen zur\u00fcckbekommt: HTML, JS, CSS, Bilder, PDFs und so weiter.<\/p>\n\n\n\n
Wenn euer Crawl-Anteil in \u201eJS\u201c oder \u201eImage\u201c hoch ist, hei\u00dft das nicht automatisch \u201eschlecht\u201c. Es hei\u00dft: Googlebot l\u00e4dt viele Ressourcen \u2013 und das beeinflusst die Download-Size und Response-Time, also eure Crawl Capacity.<\/p>\n\n\n\n
Interpretation: Typische Muster und die Bedeutung<\/h3>\n\n\n\n\n- HTML dominiert<\/strong>: Meist normal, besonders bei Content-Seiten. Wenn aber HTML-Requests hoch sind und gleichzeitig viele 3xx\/4xx auftauchen: Ihr habt Navigations- oder Canonical-Chaos.<\/li>\n\n\n\n
- JS\/CSS auff\u00e4llig hoch<\/strong>: Kann bei JS-lastigen Frontends normal sein, aber es ist ein Hinweis, dass Rendering-Ressourcen mit im Spiel sind und eure Seiten \u201eteurer\u201c zu crawlen werden.<\/li>\n\n\n\n
- Bilddateien auff\u00e4llig hoch<\/strong>: H\u00e4ufig bei sehr bildlastigen Seiten, oder wenn ihr unabsichtlich massig Bild-Varianten\/Parameter erzeugt.<\/li>\n\n\n\n
- PDF auff\u00e4llig hoch<\/strong>: Klingt erst mal harmlos, ist aber oft ein Hinweis auf riesige Downloads oder doppelte Inhalte, wie PDF und HTML-Version parallel ohne klare Steuerung.<\/li>\n<\/ul>\n\n\n\n
Die fiese Wahrheit \u00fcber Download Size<\/h3>\n\n\n\n
Google zeigt in den Crawl Stats \u201eTotal Download Size\u201c als zentrale Metrik \u00fcber Zeit.<\/p>\n\n\n\n
Gro\u00dfe Downloads bedeuten nicht nur \u201eBandbreite\u201c. Sie bedeuten: Jede URL kostet mehr. Und wenn jede URL mehr kostet, wird aus \u201eGoogle crawlt 50.000 URLs pro Tag\u201c pl\u00f6tzlich \u201eGoogle crawlt 5.000\u201c, einfach nur, weil euer HTML so aufgeblasen ist, dass es als Luftschiff durchgeht.<\/p>\n\n\n\n
Response: Die Antwortcodes <\/h2>\n\n\n\n
Response als Dimension hei\u00dft: Welche Antwort Googlebot auf seine Requests bekommt. <\/p>\n\n\n\n
Viele 200er sind nicht automatisch gut, viele 404er nicht automatisch schlecht. Entscheidend ist: Welche Responses verschwenden Crawling-Zeit und welche helfen, Googles Crawl-Queue zu aufr\u00e4umen.<\/p>\n\n\n\n
404, 410, Soft-404 und warum Blocken oft d\u00fcmmer ist als L\u00f6schen<\/h3>\n\n\n\n
Google sagt sehr klar: F\u00fcr dauerhaft entfernte Seiten solltet ihr 404 oder 410 zur\u00fcckgeben; ein 404 ist ein starkes Signal, diese URL nicht mehr zu crawlen.<\/p>\n\n\n\n
Und jetzt der Teil, den viele nicht h\u00f6ren wollen: Wenn ihr URLs stattdessen per robots.txt blockt, bleiben sie laut Google viel l\u00e4nger in der Crawl-Queue und werden wieder recrawlt, sobald ihr die Blockade entfernt.<\/p>\n\n\n\n
Soft-404s (Seiten, die wie \u201enicht gefunden\u201c wirken, aber mit 200 antworten) sind laut Google pures Budget-Leak: Sie werden weiter gecrawlt und verschwenden Ressourcen. Am besten sofort eliminieren!<\/p>\n\n\n\n
3xx: Redirects sind okay \u2013 Ketten sind Folter<\/h3>\n\n\n\n
Redirects sind manchmal n\u00f6tig (Migrationen, Canonicalisierung, http\u2192https, trailing slash \u2013 ihr kennt den Zoo). Aber Google empfiehlt explizit, lange Redirect-Ketten zu vermeiden, weil sie das Crawling negativ beeinflussen. <\/p>\n\n\n\n
Ich \u00fcbersetze: Ein Redirect ist eine h\u00f6fliche Wegbeschreibung. Eine Redirect-Kette ist ein Escape-Room, in dem Googlebot irgendwann den Notausgang nimmt. Und \u201eNotausgang\u201c hei\u00dft: weniger Crawls, weniger Vertrauen in eure Crawl Health.<\/p>\n\n\n\n
Technische Ma\u00dfnahmen: So holt ihr euch Crawl Budget zur\u00fcck<\/h2>\n\n\n\n
Das ist jetzt der Moment, in dem ich gedanklich die Axt 2000 aus dem imagin\u00e4ren Werkzeugkoffer hole, weil manche URL-Strukturen nur noch mit liebevoller Gewalt zu retten sind.<\/p>\n\n\n\n
1) URL-Inventar entschlacken<\/h3>\n\n\n\n
Google nennt \u201ePerceived Inventory\u201c als einen der wichtigsten Faktoren f\u00fcr Crawl Demand \u2013 und gleichzeitig als den Faktor, den ihr am st\u00e4rksten positiv beeinflussen k\u00f6nnt. <\/p>\n\n\n\n
\n- Duplikate konsolidieren<\/strong>: Gleiche Inhalte auf mehrere URLs? Zusammenf\u00fchren, Canonicals sauber setzen, Parameter-Strategie definieren.<\/li>\n\n\n\n
- Unwichtige URLs nicht crawlen lassen<\/strong>: Google empfiehlt, wenn Konsolidierung nicht geht, unwichtige Varianten per robots.txt zu blocken. <\/li>\n\n\n\n
- Aber:<\/strong> F\u00fcr entfernte<\/em> Inhalte lieber 404\/410 statt robots.txt, damit Google die URL schneller vergisst. <\/li>\n<\/ul>\n\n\n\n
2) Crawl Capacity erh\u00f6hen<\/h3>\n\n\n\n
Wenn eine Seite eine Weile schnell antwortet, kann das Crawl Capacity Limit steigen; wenn sie langsamer wird oder Serverfehler liefert, sinkt es und Google crawlt weniger. <\/p>\n\n\n\n
\n- Serverfehler reduzieren<\/strong>: 5xx sind Crawl-Budget-Killer, weil sie Crawl Health verschlechtern und damit die Kapazit\u00e4t dr\u00fccken. <\/li>\n\n\n\n
- Antwortzeiten stabilisieren<\/strong>: Caching, Datenbank-Tuning, CDN, saubere Timeouts, weniger \u201eich generiere HTML live aus 17 Microservices\u201c-Akrobatik.<\/li>\n\n\n\n
- Seiten effizienter machen<\/strong>: Google empfiehlt explizit, Seiten effizient zu laden; schnelleres Laden kann dazu f\u00fchren, dass Google mehr Content von eurer Site lesen kann.<\/li>\n<\/ul>\n\n\n\n
3) Sitemap und Signale<\/h3>\n\n\n\n
Google empfiehlt, Sitemaps aktuell zu halten und bei aktualisierten Inhalten das lastmod<\/em>-Tag zu nutzen. <\/p>\n\n\n\n\n- Nur indexierbare URLs in die Sitemap<\/strong>: Keine 404, keine Weiterleitungen, keine Noindex-Opfer.<\/li>\n\n\n\n
- lastmod ernst nehmen<\/strong>: Nicht \u201eimmer heute\u201c, sondern tats\u00e4chliche \u00c4nderungen; sonst stumpft das Signal ab (und ja, das ist eine menschliche Metapher, aber ihr versteht).<\/li>\n<\/ul>\n\n\n\n