Wenn du deine Server-Logs regelmäßig anschaust, kennst du wahrscheinlich dieses kleine Ziehen im Bauch: Da taucht plötzlich ein Request auf, der nicht nach dem üblichen Muster aussieht. Nicht einfach ein sauberer GET auf eine HTML-Seite oder ein POST aus einem Formular, sondern etwas wie HEAD, OPTIONS, vielleicht sogar PUT, PATCH oder DELETE. Und wenn der User-Agent dann auch noch nach Google aussieht, fragt man sich schnell: Ist das echt? Ist das gefährlich? Macht Google da etwas, das ich bisher übersehen habe?
Die kurze Antwort: Ja, Googles Crawler können solche HTTP-Requests senden. Sie tun das aber nur in einem sehr kleinen Umfang. Nach der genannten Einordnung machen HEAD, OPTIONS, PUT, PATCH und DELETE zusammen weniger als 1,5 % aller Requests aus, die Googles Crawler insgesamt verschicken. Der allergrößte Teil bleibt also weiterhin das, was du erwartest: klassische Abrufe, vor allem GET, und in bestimmten Situationen auch POST.
Spannend ist weniger die Tatsache, dass diese Methoden existieren. Die kennt jeder, der schon einmal mit APIs, REST-Schnittstellen oder komplexeren Webanwendungen gearbeitet hat. Interessant ist eher, warum ein Suchmaschinen-Crawler überhaupt damit in Berührung kommt. Die Erklärung ist ziemlich unspektakulär, fast ein bisschen trocken: JavaScript. Beim Rendern von Seiten wird JavaScript ausgeführt, und dieses JavaScript kann Requests auslösen. Manchmal löst es eben nicht nur GET oder POST aus, sondern auch andere HTTP-Methoden. Dann landet so etwas in deinen Logs.
Aus meiner Erfahrung ist genau das der Punkt, an dem viele SEOs und Entwickler kurz falsch abbiegen. Sie sehen eine Methode wie DELETE und denken sofort an einen destruktiven Vorgang. Verständlich. Der Name klingt ja auch nicht gerade harmlos. Aber ein HTTP-Request in einem Log bedeutet noch nicht automatisch, dass dein Server wirklich etwas gelöscht hat oder dass Google aktiv versucht, Daten zu verändern. Entscheidend ist, wie dein Server auf solche Methoden reagiert, ob Authentifizierung im Spiel ist, welche Endpunkte angesprochen werden und ob deine Anwendung sauber zwischen Lesen, Schreiben und Löschen unterscheidet.
Google crawlt nicht nur HTML, sondern erlebt deine Seite wie ein Browser
Früher war Crawling gefühlt einfacher zu verstehen. Ein Bot ruft eine URL ab, liest HTML, folgt Links, fertig. Das ist natürlich stark vereinfacht, aber für viele klassische Websites kam man mit diesem Bild ziemlich weit. Heute ist das anders. Moderne Websites bestehen nicht nur aus statischem HTML, sondern aus JavaScript, APIs, Tracking-Skripten, dynamischen Komponenten, Lazy Loading, Frameworks und manchmal einer ganzen Menge technischem Durcheinander, das im Browser erst einmal zusammengebaut werden muss.
Wenn Google eine Seite rendert, passiert im Kern etwas Ähnliches wie in einem Browser. Skripte laufen an, Komponenten initialisieren sich, Daten werden nachgeladen. Und genau dabei können unterschiedliche HTTP-Methoden entstehen. Ein Skript fragt vielleicht eine Schnittstelle ab. Ein Framework prüft, welche Methoden ein Endpunkt unterstützt. Eine Bibliothek sendet einen Preflight-Request. Oder ein etwas unglücklich gebautes Stück JavaScript feuert Requests ab, die im normalen Nutzerfluss kaum jemand bemerkt.
Das heißt: Wenn Google beim Rendern auf JavaScript trifft, das bestimmte Netzwerkaufrufe auslöst, dann kann Google diese Aufrufe ebenfalls ausführen oder zumindest versuchen, sie auszuführen. Der Crawler ist in diesem Moment nicht einfach nur ein stiller HTML-Leser, sondern bewegt sich eher wie ein technischer Besucher durch das, was deine Website an den Browser ausliefert.
Manchmal ist es überraschend, was dabei sichtbar wird. Ich habe schon Projekte gesehen, bei denen in den Logs plötzlich API-Endpunkte auftauchten, von denen das SEO-Team gar nicht wusste, dass sie öffentlich erreichbar waren. Nicht, weil Google besonders neugierig gewesen wäre, sondern weil irgendein Frontend-Skript diese Endpunkte beim Laden einer Seite im Hintergrund angesprochen hat. Das ist dann kein „Google-Problem“. Das ist ein Architektur- oder Frontend-Thema, das durch Googles Rendering nur sichtbar wird.
Darum ist die eigentliche Botschaft ziemlich pragmatisch: Wenn Googles Crawler ungewöhnliche HTTP-Methoden senden, liegt der Auslöser oft in deinem eigenen JavaScript. Nicht unbedingt absichtlich, nicht unbedingt schlimm, aber technisch nachvollziehbar.
Was GET und POST normalerweise leisten
Um die Besonderheit einzuordnen, hilft ein kurzer Blick auf die üblichen Methoden. GET ist die klassische Abrufmethode. Ein Browser oder Bot fragt eine Ressource an: eine HTML-Seite, eine CSS-Datei, ein Bild, ein Skript, eine JSON-Datei. GET sollte grundsätzlich lesend sein. Also: Informationen holen, nichts verändern. In einer sauber gebauten Anwendung löst ein GET-Request keine Bestellung aus, löscht keine Daten und verändert keinen Zustand.
POST wird oft verwendet, wenn Daten an den Server geschickt werden. Ein Formular, ein Login, eine Suche, ein Warenkorb, eine API-Aktion. POST kann Zustände verändern. Es kann aber auch nur Daten anfordern, je nachdem, wie die Anwendung gebaut wurde. Technisch ist POST flexibler, semantisch aber oft mit „hier passiert mehr als nur Lesen“ verbunden.
Google kennt beide Methoden. Für das klassische Crawling ist GET die zentrale Methode. POST kann in bestimmten Szenarien auftauchen, aber für die Indexierung öffentlicher Inhalte sollte man sich nie darauf verlassen, dass Google Inhalte nur über POST sauber erschließt. Für SEO bleibt weiterhin sehr gültig: Wichtige Inhalte sollten über crawlbare GET-URLs erreichbar sein.
Was HEAD, OPTIONS, PUT, PATCH und DELETE bedeuten
Die anderen Methoden klingen technischer, und genau deshalb verursachen sie in Logs oft Verwirrung. Dabei haben sie jeweils eine recht klare Bedeutung — zumindest in der Theorie. In der Praxis, nun ja, da wird im Web nicht immer alles so sauber umgesetzt, wie es in Spezifikationen hübsch beschrieben ist.
HEAD ist GET sehr ähnlich, nur ohne Antwortkörper. Der Client fragt also sinngemäß: „Gibt es diese Ressource, und welche Header würdest du mir liefern?“ Der Server antwortet mit Statuscode und Headern, aber nicht mit dem eigentlichen Inhalt. Das kann nützlich sein, um Metadaten zu prüfen, Weiterleitungen zu erkennen, Dateigrößen zu erfahren oder Caching-Informationen zu lesen. Für Crawler ist HEAD grundsätzlich nicht abwegig.
OPTIONS fragt ab, welche Kommunikationsoptionen für eine Ressource verfügbar sind. Im modernen Web siehst du OPTIONS häufig im Zusammenhang mit CORS, also Cross-Origin Resource Sharing. Besonders bei API-Aufrufen aus JavaScript gibt es sogenannte Preflight-Requests. Bevor der Browser einen bestimmten Request ausführt, fragt er unter Umständen per OPTIONS, ob der Server diese Anfrage überhaupt erlaubt. Wenn Google eine Seite rendert und deren JavaScript solche API-Aufrufe vorbereitet, kann OPTIONS in den Logs erscheinen.
PUT wird klassischerweise verwendet, um eine Ressource vollständig zu erstellen oder zu ersetzen. In REST-APIs bedeutet PUT oft: „Lege diese Ressource unter dieser Adresse an oder ersetze sie.“ Das klingt aus SEO-Sicht erst einmal seltsam, weil ein Crawler ja keine Inhalte anlegen sollte. Aber wenn JavaScript einen solchen Request triggert, kann der Versuch trotzdem sichtbar werden.
PATCH ist ähnlich, aber eher für partielle Änderungen gedacht. Statt eine Ressource komplett zu ersetzen, wird nur ein Teil aktualisiert. Auch das ist typisch für APIs und Webanwendungen, nicht für klassisches Crawling.
DELETE sagt semantisch genau das, was der Name vermuten lässt: Eine Ressource soll gelöscht werden. Hier wird es emotional schnell unruhig. Niemand möchte in seinen Logs sehen, dass ein Bot DELETE-Requests an die eigene Website schickt. Aber noch einmal: Ein DELETE-Request ist nur dann gefährlich, wenn dein Server ihn ohne ausreichende Schutzmechanismen akzeptiert und tatsächlich ausführt. Eine robuste Anwendung lässt so etwas nicht einfach anonym und öffentlich passieren.
Und genau an dieser Stelle trennt sich saubere technische Arbeit von riskanter Bequemlichkeit. Wenn ein öffentlicher, nicht authentifizierter Request per DELETE etwas löschen kann, dann hast du kein Crawler-Problem. Dann hast du ein Sicherheitsproblem, das dringend behoben werden sollte.
Warum der Anteil von weniger als 1,5 % wichtig ist
Die Zahl wirkt klein, und das ist sie auch. Weniger als 1,5 % aller Requests über diese Methoden bedeutet: Du solltest das Thema ernst nehmen, aber nicht dramatisieren. Es ist kein Zeichen dafür, dass Google plötzlich das Crawling grundlegend umstellt oder dass du deine gesamte SEO-Strategie neu denken musst.
Für die meisten Websites wirst du solche Requests selten sehen. Bei sehr großen Websites, stark JavaScript-lastigen Anwendungen oder komplexen SaaS-Frontends können sie etwas häufiger auffallen. Aber selbst dann bleiben sie im Verhältnis zum normalen Crawling eher Randerscheinungen.
Ich würde das ungefähr so einordnen: Wenn du eine kleine Content-Seite betreibst und gelegentlich ein HEAD oder OPTIONS von einem Google-Crawler siehst, ist das meist kein Grund zur Aufregung. Wenn du hingegen eine große Anwendung mit vielen öffentlichen API-Endpunkten hast und plötzlich PUT, PATCH oder DELETE gegen sensible Pfade siehst, dann lohnt sich ein genauer Blick. Nicht panisch. Gründlich.
Die Zahl unter 1,5 % ist vor allem ein Beruhigungssignal. Google verwendet diese Methoden nicht massenhaft als neues Standard-Crawling-Verfahren. Sie entstehen offenbar eher nebenbei, ausgelöst durch Rendering und JavaScript-Verhalten. Das ist ein erheblicher Unterschied.
Warum Logfiles trotzdem genauer gelesen werden sollten
Viele Teams schauen in Logfiles nur dann, wenn etwas kaputt ist. Das ist schade, denn Logs sind oft ehrlicher als jedes Tool. Sie zeigen dir, was wirklich auf deinem Server passiert: welche Bots kommen, welche Statuscodes sie bekommen, welche Pfade sie abrufen, wo Weiterleitungen hängen, wo 404er entstehen, welche Ressourcen unnötig viel Crawl-Budget verbrennen.
Bei ungewöhnlichen HTTP-Methoden solltest du nicht nur auf den User-Agent schauen. User-Agents lassen sich fälschen. Wenn du wissen willst, ob ein Request wirklich von Google kommt, brauchst du eine saubere Verifizierung über IP und Reverse-DNS-Prüfung. Das klingt etwas altmodisch, ist aber wichtig. Gerade bei Methoden wie PUT oder DELETE würde ich mich nie allein auf den Namen im User-Agent verlassen.
Danach geht es um Muster. Welche URL wurde angesprochen? War es ein statischer Pfad? Ein API-Endpunkt? Eine Admin-Route? Kam ein Statuscode 200, 204, 301, 403, 405 oder 500 zurück? Ein 405 Method Not Allowed kann völlig in Ordnung sein, wenn deine Anwendung diese Methode dort nicht erlaubt. Ein 403 Forbidden kann ebenfalls sauber sein, wenn Schutzmechanismen greifen. Ein 200 OK bei DELETE auf einem sensiblen Endpunkt würde ich mir dagegen sehr genau anschauen.
Manchmal entdeckt man dabei kleine technische Peinlichkeiten. Ein Frontend ruft beim Seitenladen eine API auf, die eigentlich nur im eingeloggten Zustand relevant ist. Oder ein Script versucht, eine Session zu aktualisieren, obwohl der Nutzer anonym ist. Oder eine externe Library feuert einen Request ab, den niemand mehr auf dem Schirm hatte. Das sind keine Weltuntergänge, aber sie verraten, dass die Website mehr tut, als sie müsste.
JavaScript ist oft der eigentliche Auslöser
Der interessanteste Teil der Aussage ist für mich nicht die Liste der Methoden, sondern der Hinweis auf JavaScript. Denn das passt zu einem größeren Muster: Viele Crawling- und Indexierungsfragen sind heute eigentlich Rendering-Fragen. Und viele Rendering-Fragen sind wiederum JavaScript-Fragen.
Wenn du eine Seite so baust, dass zentrale Inhalte, Navigationen oder interne Links erst spät, dynamisch oder abhängig von API-Aufrufen erscheinen, machst du Google das Leben schwerer. Nicht unmöglich, aber schwerer. Und du erhöhst die Wahrscheinlichkeit, dass beim Rendern zusätzliche Requests entstehen. Einige davon sind harmlos. Andere kosten Ressourcen. Wieder andere führen zu Fehlern, Timeouts oder unvollständigem Rendering.
Aus SEO-Sicht ist die saubere Lösung selten besonders glamourös: Wichtige Inhalte sollten möglichst früh, stabil und ohne unnötige JavaScript-Abhängigkeiten verfügbar sein. Server-Side Rendering, statische Auslieferung, klare HTML-Strukturen, normale Links. Ja, das klingt etwas bodenständig. Aber genau diese Bodenständigkeit gewinnt bei großen Websites oft.
Natürlich heißt das nicht, dass du kein JavaScript verwenden sollst. Das wäre Unsinn. Moderne Websites brauchen JavaScript, und Google kann eine Menge davon verarbeiten. Aber es ist ein Unterschied, ob JavaScript die Nutzererfahrung erweitert oder ob JavaScript die komplette Auffindbarkeit deiner Inhalte trägt. Gerade bei SEO-kritischen Seiten würde ich immer versuchen, die Basis ohne fragiles Client-Side-Theater stabil zu halten.
Ein praktisches Beispiel aus dem Alltag
Stell dir einen Online-Shop vor. Die Produktseite lädt im HTML zunächst nur ein Grundgerüst. Preise, Verfügbarkeit, Varianten und Empfehlungen kommen über mehrere API-Aufrufe nach. Ein Script prüft außerdem, ob der Nutzer eingeloggt ist, ob Wunschlisten verfügbar sind und ob ein Warenkorb synchronisiert werden muss. Für echte Nutzer ist das vielleicht okay, sofern es schnell genug ist. Für einen Renderer entsteht aber ein kleiner Request-Zirkus.
Wenn nun eines dieser Skripte mit OPTIONS prüft, ob ein API-Endpunkt angesprochen werden darf, siehst du OPTIONS in den Logs. Wenn ein anderes Script fälschlicherweise eine Update-Route vorbereitet, kann sogar PATCH oder PUT auftauchen. Nicht weil Google shoppen gehen will. Sondern weil der ausgelieferte Code diese Wege anbietet oder anstößt.
In solchen Fällen ist die beste Frage nicht: „Warum macht Google das?“ Sondern: „Warum liefert meine Seite JavaScript aus, das solche Requests beim Rendern auslöst?“ Diese Perspektive ist oft produktiver.
Was du jetzt konkret prüfen solltest
Wenn du solche Requests in deinen Logs findest, würde ich zuerst Ruhe bewahren. Ein einzelner HEAD- oder OPTIONS-Request ist technisch ziemlich normal. Auch ein seltener PUT-, PATCH- oder DELETE-Versuch muss nicht automatisch heißen, dass etwas schiefgelaufen ist. Aber du solltest die Situation sauber einordnen.
Prüfe zunächst, ob der Request wirklich von einem Google-Crawler stammt. Danach schaust du dir den betroffenen Pfad an. Ist es eine öffentliche URL? Eine API? Ein Admin-Endpunkt? Eine Route, die eigentlich gar nicht erreichbar sein sollte? Anschließend ist der Statuscode entscheidend. Wenn dein Server Methoden, die dort nichts zu suchen haben, mit 405 oder 403 beantwortet, ist das meist ein gutes Zeichen. Wenn er mit 200 antwortet, musst du verstehen, was genau passiert ist.
Dann lohnt sich ein Blick ins Frontend. Suche im JavaScript nach den betroffenen Endpunkten. Manchmal findest du sehr schnell die Ursache: eine alte API-Integration, ein ungenutztes Modul, ein Debug-Skript, eine Tracking-Komponente oder ein Framework-Verhalten. Gerade in gewachsenen Projekten liegt viel Code herum, den niemand mehr bewusst verantwortet. Der Browser führt ihn trotzdem aus. Und der Renderer eben möglicherweise auch.
Wichtig ist außerdem deine Serverkonfiguration. Methoden, die du nicht brauchst, sollten nicht großzügig akzeptiert werden. Viele Webserver, Frameworks und Firewalls lassen sich so konfigurieren, dass unerwünschte Methoden blockiert oder sauber abgewiesen werden. Das ist keine SEO-Sondermaßnahme, sondern normale technische Hygiene.
Blockiere aber nicht blind alles, nur weil es ungewohnt aussieht. OPTIONS kann für legitime CORS-Abläufe nötig sein. HEAD kann für technische Prüfungen sinnvoll sein. Wenn du zu grob sperrst, verursachst du womöglich neue Fehler. Besser ist eine differenzierte Regel: erlauben, was gebraucht wird; verweigern, was an der jeweiligen Route nichts verloren hat.
Was das für SEO wirklich bedeutet
Für SEO ist die Kernaussage angenehm unspektakulär: Du musst nicht davon ausgehen, dass Google deine Website plötzlich über PUT, PATCH oder DELETE crawlt. Diese Methoden spielen mengenmäßig eine sehr kleine Rolle. GET bleibt für das Crawling und die Indexierung öffentlicher Inhalte zentral. Wenn deine wichtigsten Seiten nur über komplexe API-Flows oder POST-Mechaniken erreichbar sind, ist das weiterhin keine gute Idee.
Gleichzeitig zeigt das Thema, dass technische SEO nicht bei Meta-Titles und internen Links endet. Wer moderne Websites optimiert, muss verstehen, was beim Laden und Rendern passiert. Welche Requests feuert die Seite ab? Welche davon sind notwendig? Welche Ressourcen blockieren? Welche Endpunkte liefern Fehler? Welche Inhalte erscheinen erst nach mehreren asynchronen Schritten?
Ich würde hier keinen künstlichen Alarm machen. Aber ich würde das Thema als Erinnerung nehmen: Deine Website wird nicht nur als HTML-Dokument bewertet, sondern als technisches Gesamtsystem. Der Crawler trifft auf das, was du auslieferst. Wenn du saubere, schlanke, nachvollziehbare Seiten baust, gibt es weniger Überraschungen. Wenn dein Frontend ein undurchsichtiges Netzwerk aus APIs, Seiteneffekten und alten Skripten ist, wird Crawling ebenfalls unübersichtlicher.
Das klingt vielleicht ein bisschen streng, aber es ist in der Praxis oft der Unterschied zwischen einer Website, die stabil performt, und einer, bei der SEO-Fehler nur mühsam erklärbar sind. Logs können hier ein sehr guter Lehrer sein. Nicht besonders freundlich, aber ehrlich.
Die wichtigste Einordnung zum Schluss
Googles Crawler können also mehr als nur GET und POST senden. HEAD, OPTIONS, PUT, PATCH und DELETE kommen vor, aber sie machen nur einen winzigen Anteil der gesamten Crawler-Requests aus. Der Grund liegt offenbar häufig darin, dass JavaScript beim Rendering solche Requests auslöst. Es ist weniger ein Zeichen für eine neue Crawling-Strategie, sondern eher ein Nebenprodukt moderner Webtechnologie.
Für dich heißt das: Beobachte deine Logs, prüfe ungewöhnliche Methoden nüchtern und achte darauf, dass deine Anwendung sicher und methodisch sauber reagiert. Wenn eine Methode an einem Endpunkt nichts zu suchen hat, sollte dein Server sie ablehnen. Wenn JavaScript unnötige Requests auslöst, räume auf. Und wenn du wichtige SEO-Inhalte hast, mach sie so zugänglich wie möglich: klar, stabil, per GET erreichbar und nicht vollständig abhängig von einem wackeligen Renderpfad.
Am Ende ist das Thema ein gutes Beispiel dafür, wie klein technische Details wirken können und wie viel sie über eine Website verraten. Ein einzelner OPTIONS-Request ist selten spannend. Ein Muster aus unnötigen API-Aufrufen, fehlerhaften Statuscodes und riskanten Methoden dagegen schon. Genau dort solltest du hinschauen. Nicht aus Panik, sondern aus professioneller Neugier. Denn meistens liegt die beste Optimierung nicht darin, Google zu „kontrollieren“, sondern darin, die eigene Website so sauber zu bauen, dass selbst ungewöhnliche Crawler-Requests keine unangenehmen Überraschungen auslösen.
