Google-Suchoperatoren für SEO: site:, inurl: & Co.

Wer site:, intitle: oder filetype: in das normale Google-Suchfeld tippt, bekommt keine gewöhnliche Trefferliste, sondern gefilterte Rohdaten aus dem Index – kostenlos, ohne Login, in Sekunden verfügbar. Für die tägliche SEO-Arbeit sind Suchoperatoren deshalb kein Nice-to-have, sondern der schnellste Zugriff auf Fragen, für die man sonst erst ein Tool öffnen müsste: Ist diese Seite überhaupt indexiert? Duplizieren zwei Domains denselben Text? Welche Dokumente hat ein Wettbewerber öffentlich online?

Dieser Artikel ist eine praktische Referenz für die Operatoren, die im SEO-Alltag tatsächlich etwas bringen: site:, intitle:, inurl:, Anführungszeichen, Minus und filetype:. Er zeigt auch ehrlich, wo ihre Grenzen liegen – vor allem bei der Ergebniszahl hinter site:, die viele für eine Indexgröße halten, obwohl sie das nicht ist.

Was Suchoperatoren leisten – und was nicht

Suchoperatoren sind Modifikatoren, die direkt in das normale Google-Suchfeld gehören. Es gibt keine separate Oberfläche, kein Dashboard, keinen Export – das Ergebnis ist exakt die Trefferliste, die Google in diesem Moment für diese eine Abfrage anzeigt. Das macht sie schnell, aber auch flüchtig: Ein Operator liefert eine Momentaufnahme, keinen Bericht, den man später erneut abrufen oder mit dem Vormonat vergleichen kann.

Für strukturierte, historische Daten – tatsächlicher Indexierungsstatus je URL, Crawling-Fehler, Klick- und Impressionszahlen – ist die Google Search Console das richtige Werkzeug. Suchoperatoren ersetzen das nicht, sie ergänzen es: Sieht man dort eine Auffälligkeit oder will man schnell etwas gegenprüfen, ohne extra ein Tool zu öffnen, sind Operatoren die schnellere Route für die erste Einschätzung.

site: – ob eine Seite überhaupt im Index ist

Der site:-Operator schränkt die Suche auf eine Domain, Subdomain oder einen Pfad ein. site:beispiel.de zeigt eine Auswahl an Seiten, die Google unter dieser Domain im Index hat; site:beispiel.de/blog grenzt das auf ein Verzeichnis ein. Kombiniert mit einem Begriff – etwa site:beispiel.de rückgabe – prüft man, ob eine bestimmte Seite zu einem bestimmten Wort überhaupt im Index auftaucht.

Der häufigste praktische Einsatz ist der binäre Check nach einer Veröffentlichung oder Migration: site:beispiel.de/neue-seite-slug. Erscheint die Seite, ist sie zumindest zu diesem Zeitpunkt indexiert; erscheint sie nicht, fehlt entweder die Indexierung, oder die Seite wurde durch eine noindex-Direktive, einen Crawling-Block oder eine Konsolidierung über Canonical oder Redirect ausgeschlossen. Für die genaue Ursache braucht man wieder die Search Console – site: liefert nur das Ja oder Nein, nicht das Warum.

Was site: NICHT ist: eine verlässliche Kennzahl für die Indexgröße einer Domain. Die Zahl hinter „Ungefähr X Ergebnisse“ ist eine grobe algorithmische Schätzung, keine Auszählung aus einer Datenbank. Sie schwankt zwischen zwei Abfragen derselben Suche, unterscheidet sich je nach Rechenzentrum, Sprache und Personalisierung und wird bei sehr großen wie bei sehr kleinen Domains besonders unzuverlässig. Wer diesen Zähler über mehrere Wochen protokolliert, um daraus einen Indexierungstrend abzuleiten, misst in Wahrheit Rauschen. Für belastbare Zahlen zur Indexabdeckung ist der Bericht „Seitenindexierung“ der Search Console die richtige Quelle; site: bleibt der schnelle Stichprobencheck für eine einzelne URL oder ein einzelnes Verzeichnis, nicht die Messgröße für einen Trend.

Ein Grenzfall in der Praxis: Nach dem Einreichen einer Sitemap zeigt site: manchmal deutlich weniger Seiten, als die Sitemap enthält, obwohl in der Search Console längst „Indexiert“ vermerkt ist. Das ist kein Widerspruch, sondern ein Effekt der Stichprobenlogik: site: gibt nur eine gefilterte Auswahl zurück, nicht die vollständige Liste. Wer diesen Unterschied als Beweis für ein Indexierungsproblem nimmt, jagt einem Phantom nach – die Search Console bleibt in diesem Fall die Instanz, der man glaubt, nicht die site:-Trefferzahl.

intitle: und inurl: – Muster in Titeln und Adressen aufdecken

intitle: filtert auf Seiten, die ein bestimmtes Wort im Title-Tag stehen haben; inurl: filtert auf ein Wort oder Fragment in der URL selbst. Beide lassen sich mit site: kombinieren und werden dadurch zu einem schnellen Audit-Werkzeug für die eigene Domain.

Ein typischer Fall: Man will wissen, wie viele Seiten der eigenen Domain denselben Kernbegriff im Title führen – ein Hinweis auf Keyword-Kannibalisierung. intitle:"begriff" site:beispiel.de listet genau diese Seiten. Zielen mehrere URLs klar auf dieselbe Suchintention, ist das ein Kandidat für Konsolidierung oder eine schärfere Abgrenzung der Themen gegeneinander.

inurl: eignet sich, um Adressmuster zu prüfen, die man sonst mühsam durchklicken müsste: inurl:test site:beispiel.de findet vergessene Testseiten, inurl:duplicate oder ein Parametername in der URL kann Adressen aufdecken, die eigentlich per robots.txt oder Canonical ausgeschlossen sein sollten. Bei größeren Websites lohnt sich zusätzlich site:beispiel.de inurl:? als schneller Überblick über Seiten mit Parametern in der URL – ein Hinweis auf Facetten-, Sortier- oder Filternavigation, die oft ungewollt eigene, dünne Indexeinträge erzeugt. Bei einem Wettbewerber zeigt inurl:blog site:wettbewerber.de, ob und wie dieser sein Blog strukturiert hat, ohne dass man die Navigation der Seite manuell durchsuchen muss.

Eine weitere Praxisanwendung: intitle:"seite nicht gefunden" site:beispiel.de findet Seiten, die zwar mit Statuscode 200 ausgeliefert werden, inhaltlich aber eine Fehlerseite sind – ein häufiges technisches Problem, bei dem eine 404-Seite versehentlich nicht als solche gekennzeichnet wird und dadurch indexierbar bleibt. Taucht eine solche Seite im Index auf, ist die Entscheidung meist eindeutig: entweder den korrekten Statuscode ausliefern oder die Seite gezielt per noindex kennzeichnen, je danach, ob unter der Adresse künftig wieder Inhalt stehen soll.

Anführungszeichen und Minus – exakte Treffer und gezielter Ausschluss

Ein Begriff in Anführungszeichen verlangt von Google eine Übereinstimmung dieser genauen Wortfolge, statt sie wie bei einer normalen Suche in Synonyme und Umstellungen aufzulösen. Das ist der Operator, mit dem man Duplicate Content über Domaingrenzen hinweg findet: Man kopiert einen ungewöhnlichen, mindestens sieben bis zehn Wörter langen Satz aus dem eigenen Content, setzt ihn in Anführungszeichen, und die Ergebnisliste zeigt jede Domain, die diesen Satz wortgleich übernommen hat.

Der Minus-Operator schließt Ergebnisse mit einem bestimmten Wort aus. Kombiniert mit der Phrasensuche wird er zum Filter: "exakter satz" -site:beispiel.de zeigt denselben Satz nur bei anderen Domains, nicht bei der eigenen – die eigentliche Frage bei einer Duplicate-Content-Suche. Genauso hilfreich bei der Wettbewerbsrecherche: Sucht man, wie ein Thema in der eigenen Branche behandelt wird, aber ohne die Ergebnisse der eigenen, bereits bekannten Seiten, hängt man -site:beispiel.de an die Abfrage an.

Ein häufiger Fehler ist, Anführungszeichen bei sehr kurzen oder sehr gängigen Sätzen einzusetzen. Ein Satz aus drei allgemeinen Wörtern kommt auf tausenden Seiten zufällig identisch vor; die Phrasensuche ist nur so aussagekräftig, wie der gewählte Ausschnitt tatsächlich ungewöhnlich ist.

filetype: – Dokumente und Ressourcen aufspüren

filetype: schränkt die Suche auf ein Dateiformat ein – am häufigsten pdf, aber auch doc, xls oder ppt funktionieren. Für die SEO-Recherche ist das ein direkter Zugang zu Inhalten, die nicht als normale HTML-Seite in der Navigation eines Wettbewerbers auftauchen: Whitepaper, Studien-PDFs, Preislisten, Vortragsfolien.

filetype:pdf site:wettbewerber.de zeigt, welche Dokumente ein Wettbewerber öffentlich, also ohne Formular-Gate, bereitstellt – ein Hinweis darauf, welche Themen er für ressourcenwürdig hält und wie er sie aufbereitet. Für eine Content-Gap-Analyse ist das eine schnelle Ergänzung: Fehlt ein vergleichbares Format zu einem Thema, das man selbst schon abdeckt, sieht man hier, wie andere es gelöst haben. filetype: eignet sich außerdem für die Vorarbeit bei der Recherche nach Ressourcen- oder Linklisten in einer Nische, etwa mit filetype:pdf "nützliche links" thema.

Ein Missverständnis, das diese Vorarbeit verzerrt: filetype:pdf findet nur Dateien, die tatsächlich als PDF ausgeliefert und von Google gecrawlt wurden. Ein Dokument, das als interaktive HTML-Seite mit Download-Link eingebunden ist, dessen eigentliche PDF-Datei aber per robots.txt blockiert ist, taucht hier nicht auf – der Operator zeigt nur, was der Crawler tatsächlich abrufen durfte. Und das Auffinden einer Seite sagt nichts über die Qualität eines Kontakts oder die Angemessenheit einer Anfrage aus – das bleibt manuelle Prüfungsarbeit, die kein Operator ersetzt.

Operatoren kombinieren: ein Workflow-Beispiel

Die größte Stärke der Operatoren zeigt sich in der Kombination. Ein Beispiel aus der Praxis: Nach der Migration einer Domain von Subdomains (blog.beispiel.de, shop.beispiel.de) auf Verzeichnisse (beispiel.de/blog, beispiel.de/shop) will man prüfen, ob alte Subdomain-Inhalte noch parallel im Index stehen – ein klassisches Duplicate-Content-Risiko nach einer Strukturänderung.

Jeder dieser Schritte dauert Sekunden und braucht kein Tool-Login. Das Ergebnis ist keine vollständige Liste – dafür ist wieder die Search Console oder ein systematischer Crawl der richtige Weg –, aber es reicht, um innerhalb von Minuten zu erkennen, ob ein Problem überhaupt existiert, bevor man einen vollständigen Audit ansetzt.

• site:blog.beispiel.de – prüft, ob die alte Subdomain überhaupt noch Treffer liefert.
• site:blog.beispiel.de -site:beispiel.de/blog – isoliert Seiten, die nur noch unter der alten Adresse erscheinen, nicht unter der neuen.
• intitle:"kategorie x" site:blog.beispiel.de – findet gezielt migrierte Kategorieseiten, um den Redirect stichprobenhaft zu prüfen.
• "charakteristischer satz aus der alten seite" -site:beispiel.de – zeigt, ob derselbe Inhalt zusätzlich auf einer dritten Domain kopiert wurde.

Wo Suchoperatoren an ihre Grenzen kommen

Operatoren sind Stichproben, keine Systeme. Drei Grenzen sind für die Praxis besonders wichtig.

Erstens verändern Personalisierung und Standort Ergebnisse, auch wenn der Operator selbst neutral wirkt. Zwei Personen, die dieselbe site:-Abfrage stellen, sehen nicht notwendigerweise dieselbe Reihenfolge oder Menge an Treffern, wenn Standort, Sprache oder Suchverlauf unterschiedlich sind. Ein Inkognito-Fenster reduziert diesen Effekt, entfernt ihn aber nicht vollständig.

Zweitens reagiert Google bei intensiver, automatisierter Nutzung – etwa einem Skript, das hunderte Abfragen hintereinander abschickt – mit einem Captcha oder einer vorübergehenden Sperre der IP-Adresse. Operatoren sind für manuelle Stichproben gedacht, nicht für automatisiertes Massen-Scraping; wer belastbare Daten in großer Zahl braucht, sollte APIs oder dedizierte Crawling-Tools nutzen, nicht die Weboberfläche der Suche.

Drittens, und das ist der Fehler mit den größten Folgen: Ein Nicht-Erscheinen in den Ergebnissen ist kein Beweis für „nicht indexiert“. Die Trefferliste ist selbst gefiltert – nach Relevanz, nach Duplikatsbereinigung, teils nach Qualitätssignalen. Eine Seite kann im Index liegen und trotzdem für eine bestimmte site:-Abfrage nicht auftauchen, wenn Google sie für diese spezifische Kombination als weniger relevant einstuft. Für eine verbindliche Aussage zu einer einzelnen URL ist die URL-Prüfung in der Search Console die richtige Instanz, nicht eine site:-Abfrage im Suchfeld.

Diese dritte Grenze zeigt sich besonders deutlich, wenn zwei Abfragen scheinbar widersprüchliche Ergebnisse liefern: site:beispiel.de/produkt-x liefert einen Treffer, intitle:"produkt x" site:beispiel.de dagegen keinen. In der Praxis bedeutet das meist, dass die Seite zwar im Index liegt, ihr aktueller Title-Tag den gesuchten Begriff aber nicht mehr enthält – etwa nach einer Umbenennung, bei der der Title aktualisiert, interne Verlinkung oder Snippets aber nicht nachgezogen wurden. Die richtige Reaktion ist dann nicht, dem Operator zu misstrauen, sondern der Diskrepanz nachzugehen: den aktuellen Title der Seite direkt im Quelltext prüfen, statt sich auf die Erinnerung zu verlassen, wie er einmal hieß.

Ein zweiter typischer Fall: filetype:pdf site:beispiel.de zeigt ein Dokument, das im aktuellen Menü der Seite nicht mehr verlinkt ist. Das PDF liegt also weiterhin im Index, obwohl es aus der Navigation entfernt wurde – eine bewusste Entscheidung wird nötig: entweder wieder sinnvoll verlinken und inhaltlich aktualisieren, oder per Redirect beziehungsweise noindex konsequent aus dem Index nehmen, statt die verwaiste URL unkontrolliert stehen zu lassen.

Wann ein anderes Werkzeug die bessere Wahl ist

Nicht jede Frage lässt sich mit einem Operator beantworten. Suchoperatoren sind die falsche Wahl, wenn eine belastbare Zahl statt einer Existenzprüfung gefragt ist, wenn ein Ergebnis über Zeit verglichen werden muss, oder wenn die Frage lautet, warum eine Seite ein bestimmtes Ranking hat, statt nur ob sie erscheint.

Für den tatsächlichen Indexierungsstatus je URL, inklusive Grund bei einem Ausschluss, ist die URL-Prüfung in der Search Console maßgeblich – site: ist hier nur der Vorab-Blick, keine Bestätigung. Für die Frage, über welche echten Suchanfragen eine Seite bereits Impressionen erhält, hilft kein Operator; das steht ausschließlich in den Leistungsdaten der Search Console. Und für die Frage, wie ein Crawler die Seite technisch sieht – Statuscodes, Ladezeiten, blockierte Ressourcen –, ist ein Server-Log oder ein dedizierter Crawl die richtige Datenquelle, nicht eine Suchabfrage im Browser.

Der praktische Richtwert: Operatoren sind der schnelle erste Griff, wenn eine Frage in Sekunden beantwortbar sein sollte. Sobald die Antwort eine Zahl sein muss, auf die man sich später verlassen will, wechselt man auf die strukturierte Quelle.