Wenn du lokale Produktanzeigen oder Bestandsdaten über das Google Merchant Center nutzt, ist diese Änderung deutlich wichtiger, als sie auf den ersten Blick klingt. Google hat seine Hilfedokumentation rund um den Google StoreBot überarbeitet, also den Crawler, der unter anderem prüfen soll, ob deine lokalen Produktseiten erreichbar sind. Der Kernpunkt: Es geht nicht nur darum, ob eine Seite im Browser für dich sichtbar ist. Entscheidend ist, ob Googles Systeme sie zuverlässig crawlen, laden, verstehen und erneut prüfen können.
Das klingt technisch, fast ein bisschen trocken. Aber aus meiner Erfahrung sind genau solche Themen oft die Ursache für ziemlich ärgerliche Merchant-Center-Probleme: Produkte werden abgelehnt, lokale Inventaranzeigen verschwinden plötzlich, und im Team fragt sich jeder, warum eigentlich. Die Website funktioniert doch. Der Kunde kann kaufen. Die Filialseite lädt. Nur eben nicht unbedingt für den Bot, der sie prüfen muss.
Die aktualisierte Dokumentation bringt vor allem mehr Klarheit in drei Bereichen: welche Crawler betroffen sind, wie Händler sie versehentlich oder bewusst blockieren und wie lange es dauert, bis behobene Probleme wieder verarbeitet werden. Besonders interessant ist die konkrete Zeitangabe: Sobald die Zugänglichkeit wiederhergestellt ist, dauert es normalerweise 12 bis 48 Stunden, bis das System die Änderung widerspiegelt und Produkte wieder freigegeben werden können.
Das ist eine brauchbare Orientierung. Nicht perfekt, aber immerhin etwas, womit du planen kannst. Wer schon einmal im Merchant Center auf eine erneute Prüfung gewartet hat, weiß: Ohne Zeitfenster fühlt sich das schnell an wie ein schwarzes Loch.
Warum der Google StoreBot für dich überhaupt relevant ist
Der Google StoreBot ist kein gewöhnlicher Besucher deiner Website. Er kommt nicht vorbei, um sich umzusehen, sondern um bestimmte Informationen zu prüfen. Vor allem bei lokalen Produktseiten ist das wichtig. Wenn du Produkte bewirbst, die in einem Geschäft vor Ort verfügbar sind, muss Google nachvollziehen können, ob die Zielseite erreichbar ist und ob die bereitgestellten Daten stimmen können.
Stell dir das ganz praktisch vor: Du betreibst einen Shop mit mehreren Filialen. Im Merchant Center meldest du, dass ein bestimmtes Produkt in einer Filiale verfügbar ist. Google will dann sicherstellen, dass die verlinkte Seite nicht ins Leere läuft, nicht blockiert ist, nicht nach fünf Sekunden in eine Fehlerseite kippt und nicht nur echten Nutzern, aber keinem Crawler, Inhalte zeigt. Wenn der StoreBot hier scheitert, kann das dazu führen, dass deine Produkte nicht mehr in lokalen Inventaranzeigen erscheinen.
Und genau da wird es heikel. Denn viele Händler denken bei Crawling-Problemen sofort an den klassischen Googlebot. Der ist natürlich weiterhin relevant. Aber bei Shopping-, Merchant-Center- und lokalen Inventarthemen spielen eben auch spezialisierte Crawler eine Rolle. Die überarbeitete Hilfe macht klarer, dass nicht nur ein einziger Bot betrachtet werden darf. Es geht unter anderem um StoreBot, Googlebot und Googlebot-Image.
Das klingt nach einer Feinheit, ist aber in der Praxis oft der Unterschied zwischen „alles sieht gut aus“ und „warum wird mein Produkt abgelehnt?“. Ich habe solche Fälle schon gesehen: Die robots.txt erlaubt Googlebot, aber irgendeine Firewall-Regel behandelt andere Google-Crawler strenger. Oder Bilder dürfen nicht geladen werden, weil Googlebot-Image blockiert ist. Dann ist die Seite halb zugänglich, halb kaputt. Für Menschen kaum sichtbar, für Systeme aber ein echtes Problem.
Die wichtigste Änderung: Nach der Fehlerbehebung dauert es meist 12 bis 48 Stunden
Eine der auffälligsten Ergänzungen ist die Aussage, dass es nach der Wiederherstellung der Zugänglichkeit in der Regel 12 bis 48 Stunden dauert, bis das System die Änderung verarbeitet und Produkte wieder genehmigt werden können. Google erklärt dazu, dass diese Zeit benötigt wird, um zu prüfen, ob die angegebenen Landingpages wieder gecrawlt werden können. Erst danach können die Produkte erneut in lokalen Inventaranzeigen erscheinen.
Das ist für dich besonders wichtig, wenn du unter Zeitdruck stehst. Vielleicht läuft gerade eine Aktion, ein Wochenendverkauf oder eine saisonale Kampagne. Dann ist es natürlich bitter, wenn lokale Anzeigen ausfallen. Aber du solltest wissen: Wenn du die Ursache behoben hast, heißt das nicht, dass alles in derselben Minute wieder live ist. Das System braucht Zeit zur erneuten Verarbeitung.
Ich würde dieses Zeitfenster auch nicht zu knapp interpretieren. „Typischerweise 12 bis 48 Stunden“ klingt nach einem Normalfall, nicht nach einer Garantie. Wenn deine Website komplex ist, viele Produkte betroffen sind oder es mehrere technische Sperren gab, kann es gefühlt länger dauern. Manchmal ist auch nicht die eigentliche Prüfung das Problem, sondern dass noch eine weitere technische Hürde übersehen wurde.
Ein kleines Beispiel: Du entfernst eine Regel in der robots.txt und denkst, damit sei alles erledigt. Tatsächlich blockiert aber zusätzlich noch eine Sicherheitslösung bestimmte User-Agents oder IP-Bereiche. Dann wartet man 48 Stunden, ärgert sich, und am Ende war der erste Fix eben nur die halbe Lösung. Deshalb lohnt es sich, nach einer Änderung nicht nur auf die Uhr zu schauen, sondern wirklich sauber zu testen.
Warum diese Wartezeit gar nicht so ungewöhnlich ist
Aus Sicht eines Systems ist die Wartezeit nachvollziehbar. Google muss nicht nur sehen, dass eine Seite einmal kurz erreichbar ist. Es muss stabil genug sein, um Vertrauen in die Landingpage zu bekommen. Gerade bei lokalen Produktanzeigen ist Qualität wichtig: Nutzer sollen nicht auf Seiten landen, die leer sind, blockiert werden oder extrem langsam reagieren.
Wenn du also die Zugänglichkeit wiederherstellst, läuft im Hintergrund eine Art erneute Validierung. Das System prüft, ob es die Landingpage crawlen kann, ob die Inhalte geladen werden, ob keine Blockaden mehr greifen und ob die Produkte wieder freigegeben werden können. Erst danach tauchen sie wieder in deinen lokalen Inventaranzeigen auf.
Für dein operatives Arbeiten bedeutet das: Plane technische Änderungen an Merchant-Center-relevanten Landingpages nicht fünf Minuten vor Kampagnenstart. Klingt banal, wird aber erstaunlich oft ignoriert. Wenn du größere Firewall-Regeln, Bot-Schutzmaßnahmen, CDN-Einstellungen oder robots.txt-Änderungen anfasst, solltest du immer einen Puffer einbauen. Lieber einen Tag früher testen als später mit roten Fehlermeldungen im Konto sitzen.
Die häufigsten Ursachen: So blockierst du Google-Crawler, ohne es zu merken
Die aktualisierte Dokumentation beschreibt mehrere typische Wege, wie Händler Googles Crawler blockieren. Dabei geht es nicht nur um offensichtliche Sperren. Manche Blockaden entstehen aus gut gemeinten Sicherheitsmaßnahmen. Andere aus Performance-Optimierungen. Und manche, nun ja, aus alten Regeln, die irgendwann jemand eingerichtet hat und die seit Jahren niemand mehr hinterfragt.
Besonders häufig genannt werden robots.txt, User-Agent-Switching, blockierte IP-Adressen, Firewall-Regeln, Fingerprinting und Probleme mit der Ladegeschwindigkeit. Jeder dieser Punkte kann dafür sorgen, dass StoreBot, Googlebot oder Googlebot-Image deine Seite nicht richtig erreichen.
robots.txt: Der Klassiker, der immer noch Ärger macht
Die robots.txt ist wahrscheinlich der bekannteste Ort, an dem Crawling erlaubt oder verboten wird. Und trotzdem passieren hier ständig Fehler. Ein kleines „Disallow“ an der falschen Stelle reicht, und wichtige Produktseiten sind nicht mehr zugänglich. Besonders tückisch ist es, wenn verschiedene Bereiche unterschiedlich behandelt werden: Produktseiten sind erlaubt, aber Ressourcen wie JavaScript, CSS oder Bilder sind blockiert. Dann kann der Crawler zwar die HTML-Seite abrufen, aber nicht sehen, was daraus beim Laden wirklich wird.
Wenn du lokale Produktseiten betreibst, solltest du nicht nur prüfen, ob die URL selbst erlaubt ist. Prüfe auch, ob alle wichtigen Ressourcen geladen werden dürfen. Eine Produktseite ohne Bild, ohne strukturierte Inhalte oder ohne korrekt geladene Varianten kann schnell anders wirken, als du denkst.
Manchmal ist es überraschend, wie kleine Altlasten hier wirken. In einem Projekt hatte ich einmal eine robots.txt-Regel gesehen, die ursprünglich für eine alte Staging-Struktur gedacht war. Jahre später passten neue Produkt-URLs zufällig in dasselbe Muster. Ergebnis: Google durfte einen relevanten Teil der Landingpages nicht crawlen. Niemand hatte diese Regel mehr auf dem Schirm. Genau solche Dinge sind gemein, weil sie nicht nach einem großen technischen Defekt aussehen.
User-Agent-Switching: Wenn Bots anders behandelt werden als Nutzer
Ein weiterer Punkt ist User-Agent-Switching. Damit ist gemeint, dass dein Server unterschiedliche Inhalte oder Reaktionen ausliefert, je nachdem, welcher User-Agent anfragt. Das kann legitim sein, etwa bei mobilen Darstellungen. Es kann aber problematisch werden, wenn Bots schlechter behandelt werden als normale Nutzer.
Wenn der StoreBot eine andere Version deiner Seite bekommt, eine Fehlermeldung sieht oder auf eine vereinfachte Seite ohne Produktinformationen umgeleitet wird, kann die Prüfung scheitern. Für dich sieht im Browser alles normal aus. Für Google aber nicht.
Hier solltest du besonders vorsichtig sein, wenn du Bot-Schutz, CDN-Regeln oder serverseitige Optimierungen verwendest. Manche Systeme erkennen Crawler anhand des User-Agents, aber nicht sauber genug. Andere blockieren unbekannte Bots pauschal. Und wenn der StoreBot nicht korrekt als legitimer Google-Crawler behandelt wird, hast du ein Problem, das schwer zu erkennen sein kann.
IP-Blockaden und Firewalls: Sicherheit kann Nebenwirkungen haben
Auch blockierte IP-Adressen und Firewall-Regeln werden ausdrücklich genannt. Das ist in der Praxis ein großes Thema. Viele Shops setzen Sicherheitslösungen ein, die verdächtige Zugriffe blockieren. Grundsätzlich ist das sinnvoll. Niemand will Scraper, Angriffe oder unnötigen Bot-Traffic ungefiltert durchlassen. Aber wenn die Filter zu grob sind, erwischen sie auch erwünschte Crawler.
Das Problem: Google-Crawler kommen nicht aus einer einzigen festen IP-Adresse, die du einmal einträgst und dann vergisst. Wenn deine Firewall sehr restriktiv arbeitet oder bestimmte Regionen, Rechenzentren oder Muster blockiert, kann es passieren, dass der StoreBot ausgesperrt wird. Noch schwieriger wird es, wenn Fingerprinting-Techniken eingesetzt werden, also Verfahren, die anhand vieler Signale entscheiden, ob ein Besucher „echt“ wirkt.
Ein Bot bewegt keine Maus, klickt nicht wie ein Mensch und verhält sich nicht wie ein normaler Browsernutzer. Wenn dein Schutzsystem solche Signale zwingend erwartet, kann es legitime Crawler als verdächtig einstufen. Das ist ungefähr so, als würdest du einen Paketboten nicht ins Gebäude lassen, weil er keinen Einkaufswagen dabei hat. Formal wirkt die Regel vielleicht logisch, praktisch verhindert sie aber genau die Lieferung, die du brauchst.
Ladegeschwindigkeit ist nicht nur SEO, sondern auch Zugänglichkeit
Interessant ist auch, dass Page-Speed-Probleme als mögliche Ursache genannt werden. Viele denken bei Ladezeit sofort an Rankings oder Nutzererfahrung. Beides stimmt. Aber bei Merchant-Center-Prüfungen kann schlechte Performance zusätzlich bedeuten, dass ein Crawler die Seite nicht zuverlässig verarbeiten kann.
Wenn deine Landingpage extrem langsam lädt, Timeouts produziert oder wichtige Inhalte erst sehr spät nachlädt, wirkt sie aus Sicht des Crawlers eventuell nicht zugänglich. Das gilt besonders für Seiten, die stark auf JavaScript setzen. Wenn die Produktinformationen erst nach mehreren API-Requests erscheinen, der Server aber träge reagiert, kann das für Maschinen ziemlich unsauber aussehen.
Ich bin kein Freund davon, jede technische Frage nur auf Ladezeit zu reduzieren. Es gibt schnelle Seiten, die trotzdem falsch konfiguriert sind. Und es gibt etwas langsamere Seiten, die stabil funktionieren. Aber bei lokalen Produktanzeigen würde ich Ladezeit nicht unterschätzen. Eine Seite, die für Nutzer gerade noch erträglich ist, kann für automatisierte Prüfungen schon schwierig sein.
Für dich heißt das: Wenn Produkte wegen nicht erreichbarer Landingpages beanstandet werden, schau nicht nur auf Sperren. Schau auch auf Serverantwortzeiten, Weiterleitungsketten, JavaScript-Abhängigkeiten, Bildladeprobleme und CDN-Verhalten. Gerade Weiterleitungen werden gern übersehen. Eine URL aus dem Feed führt auf eine Zwischen-URL, dann auf eine Filialauswahl, dann vielleicht auf eine Tracking-Variante. Für Menschen funktioniert das per Browser. Für Crawler kann es unnötig fehleranfällig werden.
Was du nach einer Behebung konkret prüfen solltest
Wenn du eine Sperre oder ein Ladeproblem behoben hast, solltest du nicht einfach hoffen, dass alles wieder läuft. Prüfe zuerst, ob die betroffenen Landingpages mit den relevanten Google-Crawlern erreichbar sein sollten. Kontrolliere deine robots.txt, deine Serverlogs und deine Firewall-Protokolle. Gerade Logs können sehr aufschlussreich sein, auch wenn sie nicht gerade sexy sind. Dort siehst du, ob Anfragen ankommen, welchen Statuscode sie erhalten und ob auffällige 403-, 404-, 429- oder 5xx-Fehler auftreten.
Statuscodes sind hier entscheidend. Eine Seite, die im Browser schön aussieht, aber für den Bot einen 403 liefert, ist nicht zugänglich. Eine Seite, die manchmal 200 und manchmal 503 liefert, ist instabil. Eine Seite, die zu oft 429 „Too Many Requests“ zurückgibt, wirkt so, als würdest du den Crawler drosseln oder abweisen.
Achte außerdem auf Bilder. Wenn Googlebot-Image blockiert ist, kann das bei produktbezogenen Anzeigen ebenfalls zum Problem werden. Produktseiten leben nicht nur vom Text. Bilder sind ein zentraler Bestandteil der Produktdarstellung. Wenn der Bot sie nicht abrufen kann, ist die Prüfung unvollständig.
Und ja, manchmal muss man nach dem Fix einfach warten. Diese 12 bis 48 Stunden sind nicht dazu da, dich zu ärgern, sondern Teil der erneuten Verarbeitung. Trotzdem würde ich währenddessen kontrollieren, ob neue Fehlermeldungen auftauchen oder ob dieselben URLs weiterhin nicht erreichbar wirken. Wenn nach zwei Tagen nichts passiert ist, spricht viel dafür, dass noch ein anderes Problem offen ist.
Was das für Merchant-Center-Nutzer bedeutet
Wenn du das Google Merchant Center nutzt, solltest du diese Aktualisierung ernst nehmen. Nicht panisch, aber aufmerksam. Die Änderungen zeigen ziemlich klar, dass Google stärker erklärt, wie technische Zugänglichkeit bei lokalen Produktseiten bewertet wird. Das ist hilfreich, weil es weniger Raum für Rätselraten lässt.
Besonders wichtig ist die Erkenntnis: Eine funktionierende Website reicht nicht automatisch. Deine Seiten müssen für die richtigen Crawler erreichbar sein, dürfen nicht durch Sicherheitsmechanismen blockiert werden, müssen relevante Ressourcen ausliefern und sollten schnell genug laden. Erst dann kann das System nach einer Störung wieder zuverlässig prüfen, ob deine Produkte freigegeben werden können.
Aus meiner Sicht solltest du daraus eine einfache Routine ableiten. Wenn du lokale Inventaranzeigen betreibst, dann gehören Crawling-Checks zu deinen regelmäßigen technischen Kontrollen. Nicht erst, wenn Produkte abgelehnt werden. Prüfe bei größeren Website-Deployments, CDN-Änderungen, Firewall-Updates oder Bot-Schutz-Anpassungen immer, ob Google-Crawler weiterhin sauber durchkommen. Das ist nicht glamourös, aber es spart dir im Zweifel Umsatz.
Auch im Zusammenspiel zwischen Marketing, Entwicklung und IT-Security ist das Thema wichtig. Häufig optimiert ein Team für Sicherheit, ein anderes für Performance und ein drittes für Kampagnenreichweite. Jeder macht seinen Job, aber niemand sieht das Gesamtbild. Dann blockiert eine neue Regel plötzlich legitime Crawler, und die Anzeigenabteilung bekommt die Fehlermeldung. Solche Situationen lassen sich vermeiden, wenn klar ist: StoreBot, Googlebot und Googlebot-Image sind keine Störfaktoren, sondern technische Voraussetzungen für bestimmte Google-Funktionen.
Mein praktischer Rat
Wenn du betroffen bist oder solche Probleme vermeiden willst, geh pragmatisch vor. Prüfe zuerst die offensichtlichen Dinge: robots.txt, Statuscodes, Weiterleitungen und Serverfehler. Danach kommen Firewall, CDN, Bot-Schutz und User-Agent-Regeln. Und erst dann würde ich mich in kompliziertere Sonderfälle verbeißen.
Wichtig ist vor allem, nicht nur eine einzelne URL zu testen. Nimm mehrere typische Landingpages: ein Produkt mit hoher Verfügbarkeit, eines mit Varianten, eines mit Filialbezug, vielleicht auch eine Seite mit Bildern oder dynamischen Bestandshinweisen. So bekommst du ein realistischeres Bild. Einzeltests können täuschen.
Nach der Behebung solltest du mit dem genannten Zeitfenster rechnen. 12 bis 48 Stunden sind die normale Erwartung, bis Änderungen sichtbar werden und Produkte wieder genehmigt werden können. Wenn du schon am dritten Tag bist und nichts passiert, würde ich wieder technisch nachfassen. Nicht hektisch, aber gründlich.
Am Ende ist die Botschaft ziemlich klar: Für lokale Produktanzeigen ist technische Erreichbarkeit kein Nebenthema. Sie ist die Grundlage. Wenn der StoreBot deine Seiten nicht sauber aufrufen kann, hilft dir der schönste Feed und die beste Kampagne wenig. Sorge also dafür, dass Google die Landingpages crawlen kann, halte Sicherheitsregeln präzise statt pauschal, und unterschätze Ladezeitprobleme nicht. Das ist vielleicht nicht der spannendste Teil des Online-Marketings, aber einer von denen, die im Hintergrund Umsatz sichern.
