SEO für die Ecommerce-Site-Search

TL;DR — Ihr Shop hat ein Suchfeld, und SEO-seitig sind das zwei getrennte Themen. Das Suchfeld selbst ist wertvoll: Nutzer mit Suchfeld sind oft kaufnah, und ihre Eingaben zeigen kostenlos, was Ihre Kunden tatsächlich suchen. Die erzeugten Seiten (Adressen wie /search?q=running-shoes) sind das Problem: Sie sind dünn, wiederholen sich und können unendlich zahlreich werden. Die Hauptaufgabe ist, diese Suchergebnis-URLs aus Google herauszuhalten und das Suchfeld samt den Eingaben trotzdem zu Ihrem Vorteil zu nutzen.

Was hier mit „Site Search“ gemeint ist

Zwei Arten von „Suche“ werden häufig vermischt; trennen wir sie:

• Google- (oder Bing-)Suche — die Websuche, die Menschen zu Ihrem Shop führt.
• Site Search / interne Suche — das kleine Suchfeld in Ihrem Shop, mit dem Käufer Ihre eigenen Produkte durchsuchen.

Hier geht es um die zweite Art. Gibt jemand im Suchfeld Ihres Shops „wasserdichte Stiefel“ ein, erzeugen die meisten Websites eine neue Ergebnis-URL, etwa yourstore.com/search?q=waterproof-boots. Genau dieser Teil ist für SEO wichtig.

Warum das Suchfeld gut ist

Käufer, die das Suchfeld verwenden, sind meist entschlossener als reine Browsing-Nutzer — sie haben genau gesagt, was sie möchten. Das bringt zwei Vorteile:

1. Es steigert Conversions. Ein schnelles, präzises Suchfeld, das Tippfehler und Synonyme („trainers“ = „sneakers“) versteht, hilft Menschen, Produkte zu finden und zu kaufen.
2. Es ist eine kostenlose Keyword-Liste. Jede Eingabe ist ein echter Kunde, der in eigenen Worten sagt, wonach er sucht. Das hilft bei der Sortimentsplanung, bei Inhalten und bei der Entscheidung, welche Kategorien entstehen sollten.

Warum die Ergebnisseiten ein Problem sind

Der Haken: /search?q=...-Seiten können unbemerkt drei Probleme verursachen:

1. Es gibt endlose Varianten. Menschen geben Millionen verschiedener Begriffe ein, einschließlich Tippfehlern und Unsinn; jede Eingabe kann eine eigene URL erzeugen.
2. Sie sind dünn und wiederholen sich. Eine Suche nach „rote Schuhe“ und eine Kategorie für rote Schuhe können fast dieselben Produkte zeigen, sodass Google nahezu doppelte Seiten sieht.
3. Einige sind leer. Eine Suche nach etwas, das Sie nicht verkaufen, liefert „keine Ergebnisse“ — eine minderwertige Seite, die nicht in Google gehört.

Google hat nur begrenzte Zeit für das Crawling und verwendet sie lieber für echte Produkt- und Kategorieseiten als für einen Sumpf aus Suchergebnis-URLs. Die Standardempfehlung lautet daher: Interne Suchergebnisseiten aus Google heraushalten.

Die einfache Lösung

• Weisen Sie Suchmaschinen über Ihre Datei robots.txt an, die Suchergebnisseiten nicht zu crawlen. Meist genügt eine Zeile, die Ihr Entwickler oder Ihre Plattform einrichten kann.
• Sorgen Sie dafür, dass eine Suche ohne Treffer eine echte „nicht gefunden“-Antwort liefert und nicht nur leer aussieht, während sie einen normalen Status vortäuscht. Evidence for this claim A page for a resource that does not exist should return an appropriate 404 or 410 status rather than a misleading 200. Scope: A useful search interface may remain available to users while nonexistent result resources use correct status handling. Confidence: high · Verified: 2026-07-14 Google: Soft 404 errors
• Versuchen Sie nicht, das Problem gleichzeitig mit einem “noindex”-Tag und einer Sperre zu lösen. Ist die Seite blockiert, kann Google das Tag nicht lesen; die Sperre greift und das Tag bleibt wirkungslos. Wählen Sie eine Kontrolle — für diese Aufgabe ist die Sperre die richtige.

Die eine wichtige Ausnahme

Manchmal suchen viele Menschen in Ihrem Shop und bei Google nach genau demselben Begriff, etwa „glutenfreie Proteinriegel“. Gibt es dafür echte, wiederholte Nachfrage, versuchen Sie nicht, die rohe /search?q=-Seite ranken zu lassen. Bauen Sie stattdessen eine echte Kategorie- oder Landingpage mit sauberer Adresse, richtigem Titel und etwas hilfreichem Text. Eine solche Seite ist rankingwürdig; die rohe Such-URL nicht.

Sie möchten die technische Version — die genaue Begründung für robots.txt gegenüber noindex, warum leere Ergebnisse einen echten 404 brauchen und wie sich Suchprotokolle in indexierbare Seiten überführen lassen? Wechseln Sie zum Tab Fortgeschritten.

TL;DR — Ecommerce-Site-Search bezeichnet zwei Themen unter einem Namen; entscheidend ist, sie auseinanderzuhalten. Das Feature ist eine Conversion-Fläche mit hoher Kaufabsicht, und seine Suchprotokolle gehören zu Ihren besten Quellen für die Keyword-Recherche. Die Ergebnisseiten (/search?q=...) bilden dagegen einen nahezu unendlichen Raum aus dünnen, fast doppelten und oft leeren URLs. Google ordnet sie neben facettierter Navigation und Sitzungskennungen als eine der wichtigsten Kategorien geringwertiger URLs ein, die “drain crawl activity from pages that do actually have value.” (Übersetzung) „Crawl-Aktivität von Seiten abziehen, die tatsächlich Wert haben.“ Die zentrale Regel lautet: robots.txt ist hier besser als noindex. Google sagt ausdrücklich: “don’t use noindex, as Google will still request, but then drop the page… wasting crawling time,” (Übersetzung) „Verwenden Sie kein noindex, denn Google ruft die Seite weiterhin ab, verwirft sie danach jedoch und verschwendet Crawling-Zeit.“ Sperren Sie deshalb den Suchpfad, damit Bots dafür kein Budget ausgeben. Kombinieren Sie für dieselbe URL nie ein Disallow in robots.txt mit noindex: Eine blockierte Seite kann nicht gelesen werden, das noindex bleibt unsichtbar und eine verlinkte URL kann im Index verbleiben. Geben Sie für leere Ergebnismengen echte 404s statt Soft-404s zurück (“soft 404 pages will continue to be crawled, and waste your budget” (Übersetzung) „Soft-404-Seiten werden weiter gecrawlt und verschwenden Ihr Budget.“). Wenn eine Anfrage echte, wiederholte Nachfrage zeigt, indexieren Sie nicht die rohe Such-URL, sondern erstellen Sie eine passende Kategorie- oder Landingpage.

Zwei Aufgaben, die nicht zusammenfallen

Site-Search-SEO verwirrt, weil der Begriff zwei fast unabhängige Aufgaben bündelt:

1. Das Sucherlebnis gut machen. Relevanz, Geschwindigkeit, Tippfehlertoleranz, Synonyme, Merchandising, Umgang mit null Treffern und — entscheidend — die Auswertung der Query-Logs für Nachfragesignale. Das ist UX- und CRO-Arbeit mit SEO-Nutzen.
2. Ergebnis-URLs aus der organischen Suche heraushalten. Verhindern Sie, dass sie Crawl-Budget verschwenden, den Index aufblasen und nahezu doppelte Seiten erzeugen.

Optimieren Sie Aufgabe 1 energisch. Bei Aufgabe 2 ist die Standardhaltung Eindämmung, mit einer gezielten Ausnahme weiter unten. Die meiste Verwirrung entsteht, wenn Begeisterung für ein gutes Sucherlebnis auf einen URL-Raum übertragen wird, der fast nie ein Ranking verdient.

Warum Suchergebnisseiten eine Crawl-Last sind

Interne Such-URLs sind ein Paradebeispiel für den geringwertigen URL-Raum, vor dem Google warnt. In Googles maßgeblichem Beitrag zum Crawl-Budget führt Gary Illyes die URL-Kategorien, die Crawl-Budget verschwenden, “in order of significance” (Übersetzung) „in absteigender Bedeutung“ auf. “Faceted navigation and session identifiers” (Übersetzung) „Facettierte Navigation und Sitzungskennungen“ stehen an erster Stelle, gefolgt von “On-site duplicate content” (Übersetzung) „internen doppelten Inhalten“ und “Soft error pages.” (Übersetzung) „Soft-Error-Seiten.“ Interne Suchergebnisseiten fallen gleichzeitig in alle drei Kategorien:

• Unendlicher, dynamischer Raum. Jede einzelne Anfrage — einschließlich Tippfehlern, Bots und Query-String-Müll — kann eine neue URL erzeugen. Das ist dieselbe Parameterexplosion, die facettierte Navigation gefährlich macht.
• Dünner, nahezu doppelter Inhalt. Eine Suche nach ?q=running-shoes und die Kategorie /shoes/running/ können fast dieselben Produkte zeigen; die Suchseite konkurriert dann mit einer Seite, die Sie tatsächlich ranken lassen möchten.
• Leere oder Soft-Error-Seiten. „Keine Ergebnisse“ ist per Definition minderwertig; bei 200 OK sind solche Seiten Soft-404s, die Google ausdrücklich als Crawl-Verschwendung betrachtet.

Die Kosten entsprechen genau Illyes’ Beschreibung: “Wasting server resources on pages like these will drain crawl activity from pages that do actually have value, which may cause a significant delay in discovering great content on a site.” (Übersetzung) „Wenn Serverressourcen für solche Seiten verschwendet werden, zieht das Crawl-Aktivität von Seiten ab, die tatsächlich Wert haben, und kann die Entdeckung guter Inhalte auf einer Website erheblich verzögern.“ In einem großen Shop können unkontrollierte Such-URLs unbemerkt zu einer der größten Crawl-Senken werden.

Eine Einschränkung zur Größenordnung ist wichtig, denn bei diesem Thema macht man sich leicht unnötig Sorgen: Google stellt klar, dass Crawl-Budget vor allem große Websites betrifft — “if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” (Übersetzung) „Wenn Ihre Seiten offenbar noch am Tag ihrer Veröffentlichung gecrawlt werden, müssen Sie diesen Leitfaden nicht lesen.“ Ein Shopify-Shop mit 500 Produkten wird wegen einiger Such-URLs nicht gedrosselt. Auch bei kleinen Websites können indexierte Suchseiten jedoch doppelte oder dünne Inhalte und Indexaufblähung verursachen. Diese Probleme sollten unabhängig vom Crawl-Budget vermieden werden, und die Eindämmung ist in beiden Fällen einfach.

robots.txt gegenüber noindex — richtig entscheiden

Das ist die Genauigkeitsachse des gesamten Themas und wird von vielen Shops falsch behandelt. Es gibt zwei Werkzeuge mit unterschiedlichen Aufgaben:

• robots.txt-Disallow stoppt das Crawling. Bots rufen die URL nicht ab und verbrauchen dafür kein Budget. Für interne Suchergebnisse ist dies das richtige Werkzeug, weil diese URLs gar nicht erst angefordert werden sollen.
• noindex verhindert die Indexierung, aber erst nach dem Crawling: Googlebot muss die Seite abrufen, um das Tag zu sehen. Es spart deshalb kein Crawl-Budget. Googles Leitfaden formuliert es unmissverständlich: “Don’t use noindex, as Google will still request, but then drop the page when it sees a noindex meta tag or header in the HTTP response, wasting crawling time.” (Übersetzung) „Verwenden Sie kein noindex, denn Google ruft die Seite weiterhin ab und verwirft sie erst, wenn es im HTTP-Antworttext ein noindex-Meta-Tag oder einen entsprechenden Header erkennt; dadurch wird Crawling-Zeit verschwendet.“ Quelle zum Zitat

Für das Standardziel „Suchseiten aus Google und aus dem Crawl-Zeitplan heraushalten“ gilt deshalb: Sperren Sie den Suchpfad in robots.txt.

User-agent: *
Disallow: /search
Disallow: /*?q=
Disallow: /*?s=

(Passen Sie den Pfad an die Plattform an — /search, ?q=, ?s=, /catalogsearch/ bei Magento und andere Varianten.)

Der entscheidende Fehler: dieselbe URL niemals gleichzeitig sperren und mit noindex versehen. Ist eine URL in robots.txt blockiert, kann Googlebot sie nicht abrufen und damit auch das gesetzte noindex-Tag nicht sehen. Evidence for this claim Google must crawl a page to see noindex, so a robots.txt block prevents Google from processing that page's noindex rule. Scope: Robots.txt controls crawling, while noindex controls indexing after retrieval. Confidence: high · Verified: 2026-07-14 Google: Block indexing with noindex Die Sperre gewinnt; das Tag bleibt unsichtbar. Eine robots-gesperrte URL kann bei einem externen Link trotzdem als nackte URL indexiert werden, weil robots.txt das Crawling und nicht die Indexierung kontrolliert.

• Ziel: Crawl nicht verschwenden und nicht ranken → robots.txt-Disallow (der Normalfall für Suchseiten).
• Ziel: bereits indexierte Seiten entfernen → Crawling vorübergehend erlauben und noindex ausliefern, bis sie verschwinden; danach zur künftigen Crawl-Einsparung sperren. Niemals beides gleichzeitig einsetzen.

Leere Ergebnisse: echte 404, keine Soft-404

Wenn eine Suche keine Treffer liefert, ist eine 200 OK-Seite mit „keine Ergebnisse“ die falsche Lösung. Sie ist eine Soft-404, und Google warnt: “soft 404 pages will continue to be crawled, and waste your budget.” (Übersetzung) „Soft-404-Seiten werden weiter gecrawlt und verschwenden Ihr Budget.“ Evidence for this claim Soft-404 pages can continue to consume crawl resources because they return a success response for missing content. Scope: Google may classify pages algorithmically based on content and response behavior. Confidence: high · Verified: 2026-07-14 Google: Large-site crawl budget Für eine Null-Treffer-Seite sind diese Optionen besser:

• Geben Sie einen echten 404-Status (oder 410) zurück, damit Google “a strong signal not to crawl that URL again.” (Übersetzung) „ein starkes Signal erhält, diese URL nicht erneut zu crawlen.“
• Oder bieten Sie ein hilfreiches „keine Ergebnisse“-Erlebnis hinter einer URL an, die bereits in robots.txt gesperrt ist. Wenn Bots /search nie crawlen, spielt der Statuscode der leeren Seite für das Crawl-Budget keine Rolle. Sie können die Seite dann ganz darauf ausrichten, den Käufer zurückzugewinnen, etwa mit vorgeschlagenen Kategorien, beliebten Produkten und Rechtschreibvorschlägen.

UX- und Crawl-Lösung widersprechen sich nicht: Sperren Sie den Suchpfad für Bots und gestalten Sie die Null-Treffer-Seite für Menschen ausschließlich auf Conversion-Rückgewinnung.

Wann Sie tatsächlich eine indexierbare Seite möchten

Eindämmung ist der Standard, aber in Suchlogs steckt eine echte Long-Tail-Chance. Der Fehler wäre, sie durch die Indexierung roher /search?q=-URLs zu nutzen. Tun Sie stattdessen Folgendes:

1. Suchprotokolle auswerten. Die internen Suchanfragen sind eine First-Party-Liste der Nachfrage in den eigenen Worten Ihrer Kunden — einschließlich Produktlücken und Formulierungen, die Ihre Kategorien noch nicht abdecken.
2. Externe Nachfrage prüfen. Gleichen Sie die wichtigsten internen Anfragen in einem Keyword-Tool mit der tatsächlichen Suchmaschinennachfrage ab. Ein Begriff mit Nachfrage im Shop und organischem Suchvolumen ist ein Kandidat.
3. Eine richtige Seite bauen, nicht die Such-URL. Erstellen Sie eine echte Kategorie- oder Collection-Seite oder eine kuratierte Landingpage unter einer sauberen statischen URL (/collections/gluten-free-protein-bars/) mit aussagekräftigem Titel, H1, BreadcrumbList, nützlichem Text und internen Links. Diese Seite verdient Indexierung und Rankings; die rohe Ergebnis-URL nicht.

Das ist dieselbe Logik wie bei facettierter Navigation: Rauschen sperren, Signal indexieren. Bei der Site Search rechtfertigt das Signal aber fast nie die Indexierung der Such-URL selbst. Überführen Sie die Nachfrage in eine eigens gebaute Seite.

Einordnung

Ecommerce-Site-Search überschneidet sich stark mit einigen Nachbarthemen. Facettierte Navigation ist der engste Verwandte: Filter und Suche sind zwei Varianten derselben Parameterexplosion. Googles Leitfaden für Facetten — robots.txt zum Sperren, 404 für leere Kombinationen und Canonical als schwächeres Langzeitwerkzeug — lässt sich fast direkt auf Such-URLs übertragen. Kategorieseiten-SEO ist der Ort, an dem Long-Tail-Nachfrage aus den Suchprotokollen tatsächlich landen sollte. Der Blick auf die Crawl-Effizienz — Kapazität und Nachfrage sowie geringwertige URLs, die Budget von echten Seiten abziehen — gehört zum Thema Crawl-Budget. Site Search macht aus dem verborgenen Crawl-Risiko des Suchfelds ein Werkzeug für die Keyword-Recherche.

KI-Zusammenfassung

Eine komprimierte Fassung der Advanced-Version:

• Ecommerce-Site-Search vereint zwei Themen. Das Feature, also das Suchfeld im Shop, ist ein Conversion-Werkzeug mit hoher Kaufabsicht und eine wertvolle First-Party-Quelle für die Keyword-Recherche. Die Ergebnisseiten (/search?q=...) sind dagegen ein SEO-Risiko. Verwechseln Sie beides nicht.
• Die Ergebnisseiten sind klassischer Crawl-Abfall. Google nennt “Faceted navigation and session identifiers” (Übersetzung) „facettierte Navigation und Sitzungskennungen“ an erster Stelle unter den geringwertigen URL-Kategorien. Interne Such-URLs folgen demselben unendlichen, dünnen, fast doppelten und oft leeren Muster und “drain crawl activity from pages that do actually have value.” (Übersetzung) „ziehen Crawl-Aktivität von Seiten ab, die tatsächlich Wert haben.“
• robots.txt ist für diese Aufgabe besser als noindex. noindex erzwingt weiterhin einen Crawl, bevor die Seite verworfen wird (“don’t use noindex, as Google will still request… wasting crawling time” (Übersetzung) „Verwenden Sie kein noindex, denn Google ruft die Seite weiterhin ab … und verschwendet Crawling-Zeit.“). Sperren Sie deshalb den Suchpfad in robots.txt, damit Bots ihn gar nicht erst abrufen.
• Kombinieren Sie für dieselbe URL nie ein Disallow mit noindex. Eine blockierte Seite kann nicht gelesen werden; Google sieht das noindex daher nicht. Eine verlinkte, blockierte URL kann trotzdem als bloße URL indexiert werden.
• Leere Ergebnisse erfordern einen echten 404 statt einer Soft-404 (“soft 404 pages will continue to be crawled, and waste your budget” (Übersetzung) „Soft-404-Seiten werden weiter gecrawlt und verschwenden Ihr Budget.“). Alternativ kann die Null-Treffer-UX hinter einem bereits gesperrten /search-Pfad liegen.
• Die Long-Tail-Ausnahme: Indexieren Sie keine rohen Such-URLs. Werten Sie Suchprotokolle aus, gleichen Sie die Nachfrage mit echtem Suchvolumen ab und erstellen Sie für geeignete Themen eine richtige Kategorie- oder Landingpage unter einer sauberen statischen URL.
• Nachbarthemen: facettierte Navigation wegen derselben Parameterexplosion, Kategorieseiten-SEO als Ziel der Nachfrage und Crawl-Budget als Effizienzrahmen.

Offizielle Dokumentation

Dokumentation aus Primärquellen. Es gibt kein einzelnes Google-Dokument mit dem Titel „interne Site Search“; die Hinweise verteilen sich auf Crawl-Budget-, Facetten- und Duplikat-URL-Dokumente, weil Suchergebnisseiten ein Beispiel desselben Problems minderwertiger URLs sind.

Google — Crawling und Crawl-Budget

• Crawl-Budget optimieren — robots.txt gegenüber noindex, Soft-404-Verschwendung, 404/410 für entfernte Seiten und die Frage, wer Crawl-Budget beachten muss.
• Was Crawl-Budget für Googlebot bedeutet — die maßgebliche Liste minderwertiger URL-Kategorien und warum sie Crawl-Aktivität von wertvollen Seiten abziehen.
• Crawling von URLs mit facettierter Navigation verwalten — das nächste Analogon zur internen Suche: robots.txt, URL-Fragmente, schwächeres Canonical und 404 für leere Kombinationen. (Crawler-Infrastruktur-Version.)

Google — Indexierung und Duplikate

• Einführung in robots.txt — was Disallow tut (Crawling sperren) und was es nicht tut (aus dem Index entfernen).
• Suche mit noindex aus dem Index entfernen — das Werkzeug zum Entfernen und die Voraussetzung, dass die Seite crawlbar bleibt.
• Doppelte URLs konsolidieren — Hintergrund zur Canonicalisierung der nahezu doppelten Suchergebnisse.

Google — Ecommerce-Spezialthema

• URL-Struktur für Ecommerce-Websites gestalten — doppelte URLs minimieren und Session-/Trackingparameter aus internen Links fernhalten.
• Google helfen, die Ecommerce-Struktur zu verstehen — warum eigens gebaute Kategorieseiten, auf denen Nachfrage aus Suchlogs landet, dynamischen URLs vorzuziehen sind.

Zitate aus den Quellen

Wörtlich dokumentierte Aussagen von Google. Jeder Link führt als Deep Link zur zitierten Passage. Google hat kein Zitat, das „interne Site Search“ ausdrücklich nennt; die folgenden Aussagen behandeln die URL-Kategorie, zu der Suchergebnisseiten gehören: Crawl-Budget-Abfall, robots.txt gegenüber noindex und Soft-404s.

Google — was Crawl-Budget verschwendet

• “Faceted navigation and session identifiers / On-site duplicate content / Soft error pages / Hacked pages / Infinite spaces and proxies / Low quality and spam content” (Übersetzung) „Facettierte Navigation und Sitzungskennungen / interne doppelte Inhalte / Soft-Error-Seiten / gehackte Seiten / unendliche URL-Räume und Proxys / minderwertige und Spam-Inhalte“ — Gary Illyes über die geringwertigen URL-Kategorien “in order of significance.” (Übersetzung) „in absteigender Bedeutung.“ Interne Suchergebnisseiten gehören zu den ersten drei Kategorien. Zum Zitat
• “Wasting server resources on pages like these will drain crawl activity from pages that do actually have value, which may cause a significant delay in discovering great content on a site.” (Übersetzung) „Wenn Serverressourcen für solche Seiten verschwendet werden, zieht das Crawl-Aktivität von Seiten ab, die tatsächlich Wert haben, und kann die Entdeckung guter Inhalte auf einer Website erheblich verzögern.“ — Gary Illyes, Google. Zum Zitat
• “An increased crawl rate will not necessarily lead to better positions in Search results… while crawling is necessary for being in the results, it’s not a ranking signal.” (Übersetzung) „Eine höhere Crawl-Rate führt nicht zwangsläufig zu besseren Positionen in den Suchergebnissen … Crawling ist zwar notwendig, um in den Ergebnissen zu erscheinen, aber kein Ranking-Signal.“ — Gary Illyes, Google. Anders gesagt: Häufigeres Crawling Ihrer Suchseiten verbessert nichts. Zum Zitat

Google — robots.txt gegenüber noindex und Soft-404

• “Don’t use noindex, as Google will still request, but then drop the page when it sees a noindex meta tag or header in the HTTP response, wasting crawling time.” (Übersetzung) „Verwenden Sie kein noindex, denn Google ruft die Seite weiterhin ab und verwirft sie erst, wenn es im HTTP-Antworttext ein noindex-Meta-Tag oder einen entsprechenden Header erkennt; dadurch wird Crawling-Zeit verschwendet.“ — Google Search Central zur Frage, warum robots.txt und nicht noindex das Werkzeug für das Crawl-Budget ist. Zum Zitat
• “soft 404 pages will continue to be crawled, and waste your budget.” (Übersetzung) „Soft-404-Seiten werden weiter gecrawlt und verschwenden Ihr Budget.“ — Google Search Central über leere Seiten ohne Treffer, die 200 OK zurückgeben. Zum Zitat
• “Return a 404 or 410 status code for permanently removed pages… a 404 status code is a strong signal not to crawl that URL again.” (Übersetzung) „Geben Sie für dauerhaft entfernte Seiten den Statuscode 404 oder 410 zurück … ein 404-Statuscode ist ein starkes Signal, diese URL nicht erneut zu crawlen.“ — Google Search Central. Zum Zitat

Google — Crawl-Budget zählt vor allem bei großen Websites

• “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” (Übersetzung) „Wenn Ihre Website nicht sehr viele Seiten besitzt, die sich schnell ändern, oder wenn Ihre Seiten offenbar noch am Tag ihrer Veröffentlichung gecrawlt werden, müssen Sie diesen Leitfaden nicht lesen.“ Zum Zitat

Welche Kontrolle für eine Suchergebnis-URL?

Arbeiten Sie von oben nach unten und stoppen Sie beim ersten passenden Fall.

1. Standardfall — Suchergebnisse, die nie gecrawlt oder gerankt werden sollen? → Den Suchpfad (/search, ?q=, ?s=, /catalogsearch/) per robots.txt disallow sperren. Bots rufen ihn nie ab; er kostet kein Crawl-Budget. Fügen Sie nicht zusätzlich noindex hinzu.

2. Sind diese Such-URLs bereits indexiert und sollen aus dem Index? → Nicht einfach sperren — eine robots-blockierte URL kann indexiert bleiben. Crawling vorübergehend erlauben und noindex ausliefern (in dringenden Fällen GSC-Entfernungstool), bis die URLs verschwinden; dann zur künftigen Einsparung sperren. Nie beides gleichzeitig.

3. Gibt es für eine bestimmte Anfrage echte, wiederholte Nachfrage (intern und extern)? → Die Such-URL nicht indexieren. Eine echte Kategorie-, Collection- oder Landingpage mit sauberer statischer URL, Titel, H1, BreadcrumbList und nützlichem Text bauen. Nachfrage auf diese Seite übertragen und den rohen Suchpfad weiter sperren.

4. Was soll eine leere Suche ohne Treffer zurückgeben? → Einen echten 404 (oder eine Null-Treffer-UX hinter dem bereits gesperrten /search-Pfad). Nie eine crawlbare 200 OK-Seite „keine Ergebnisse“ — das ist eine Soft-404 und verschwendet Budget.

5. Ist der Shop klein (am selben Tag gecrawlt und deutlich unter sechsstelligen URL-Zahlen)? → Crawl-Budget ist wahrscheinlich nicht das Problem; blockieren Sie Such-URLs trotzdem, um dünne/duplizierte Inhalte und Indexaufblähung zu vermeiden. Die Korrektur ist in jeder Größenordnung günstig.

Ecommerce-Site-Search-SEO-Checkliste

Ergebnisseiten eindämmen

• Suchpfad (/search, ?q=, ?s=, Plattformvariante) ist in robots.txt gesperrt.
• Such-URLs tragen nicht zusätzlich noindex; Sperre und noindex auf derselben URL machen das Tag unsichtbar.
• Keine internen Links geben Such-URLs Linkkraft; sie gehören nicht in Navigation, Sitemap oder Canonical-Tags.
• Such-URLs stehen nicht in der XML-Sitemap.
• Bereits indexierte Such-URLs werden korrekt bereinigt: erst Crawling erlauben + noindex, danach sperren, oder GSC-Entfernung für dringende Fälle.

Leere Ergebnisse behandeln

• Null-Treffer-Seiten geben einen echten 404 (keinen 200 OK-Soft-404) zurück oder liegen hinter einem bereits gesperrten Suchpfad.
• Das menschliche Null-Treffer-Erlebnis gewinnt den Käufer zurück: vorgeschlagene Kategorien, beliebte Produkte und Rechtschreib-/Synonymvorschläge.

Nachfrage auswerten

• Interne Suchlogs werden regelmäßig auf Produktlücken und Kundenformulierungen geprüft.
• Interne Top-Anfragen werden mit echter externer Suchnachfrage abgeglichen.
• Gewinner werden als eigens gebaute Kategorie-/Landingpages mit sauberer URL, Titel, H1, BreadcrumbList und nützlichem Text umgesetzt — nicht als indexierte Such-URLs.

Das Feature gut machen (UX/CRO)

• Suche verarbeitet Tippfehler und Synonyme.
• Suche ist schnell und liefert relevante Ergebnisse.
• Merchandising/Boosting ist für wichtige Anfragen eingerichtet, wo es zählt.

Die Denkmodelle

1. Zwei Aufgaben, ein Name. „Ecommerce Site Search SEO“ bündelt zwei unabhängige Aufgaben: das Feature gut machen (UX, CRO, Query-Log-Auswertung) und Ergebnis-URLs aus der organischen Suche heraushalten (Eindämmung). Optimieren Sie die erste Aufgabe stark und begrenzen Sie die zweite standardmäßig. Fast jeder Fehler entsteht, wenn Begeisterung aus Aufgabe 1 auf den URL-Raum von Aufgabe 2 übertragen wird.

2. Suchergebnisse sind verkleidet ein Facettenproblem. Eine ?q=-URL folgt demselben unendlichen, dünnen, nahezu doppelten und manchmal leeren Muster wie eine ?color=&size=-Facette. Dasselbe Werkzeug gilt: Rauschen mit robots.txt sperren, Leeres mit 404 behandeln, Canonical als schwächeren Rückfall verwenden und echte Nachfrage auf eine eigens gebaute Seite heben.

3. robots.txt und noindex sind nicht austauschbar. robots.txt = Crawling stoppen (spart Budget, entfernt aber keine bereits indexierte URL). noindex = Indexierung stoppen (entfernt die Seite erst nach einem Crawl und spart daher kein Budget; bei zusätzlicher Sperre ist das Tag unsichtbar). Wählen Sie das Werkzeug passend zum Ziel und kombinieren Sie beide nie auf derselben URL.

4. Das Signal liegt im Suchfeld, nicht in der URL. Der Wert der Site Search ist nicht die Ergebnisseite, sondern die Anfrage. Behandeln Sie das Suchlog als First-Party-Keyword-Datensatz. Die URL wird gesperrt; die darin sichtbare Nachfrage erhält eine echte Seite.

5. Der Maßstab bestimmt den Einsatz, nicht die Lösung. Crawl-Budget ist vor allem bei großen Websites relevant; dünne/duplizierte Inhalte und Indexaufblähung sind es immer. Die Eindämmung (Such-URLs sperren, leere Ergebnisse mit 404 behandeln) ist in jeder Shopgröße günstig und richtig.

Wie Ecommerce-Site-Search-SEO schiefgeht

Dieselbe Such-URL sperren und mit noindex versehen. Der häufigste Fehler: Wenn robots.txt blockiert, kann Googlebot das noindex-Tag nicht sehen; eine verlinkte blockierte URL kann als nackte URL indexiert bleiben. Pro Ziel nur ein Werkzeug verwenden.

noindex verwenden, um „Crawl-Budget zu sparen“. noindex stoppt das Crawling nicht. Google ruft die Seite weiterhin ab, um das Tag zu erkennen, und verwirft sie erst danach — “wasting crawling time.” (Übersetzung) „wodurch Crawling-Zeit verschwendet wird.“ Für das Crawl-Budget ist robots.txt das richtige Werkzeug.

200 OK-Seiten mit „keine Ergebnisse“ ausliefern. Eine crawlbare Null-Treffer-Seite, die 200 zurückgibt, ist eine Soft-404. Google crawlt sie weiter und wertet sie als Verschwendung. Geben Sie einen echten 404 zurück oder legen Sie die Null-Treffer-UX hinter einen bereits gesperrten Pfad.

Rohe /search?q=-URLs ranken lassen. Auch bei echter Nachfrage ist die rohe Such-URL dünn und nahezu doppelt. Bauen Sie eine eigens geplante Kategorie-/Landingpage, statt die Ergebnisseite zu indexieren.

Such-URLs aus Navigation, Sitemap oder „beliebte Suchen“-Widgets verlinken. Chips, Autocomplete-Links und Sitemap-Einträge auf /search?q= führen Crawler direkt in den einzudämmenden Raum. Interne Links sollen auf echte Kategorie- und Produktseiten zeigen.

Session-IDs und Trackingparameter auf Such-URLs zulassen. /search?q=shoes&sessionid=…&utm_… vervielfacht dieselbe dünne Seite. Session- und Trackingparameter aus internen Links heraushalten; Google ordnet Session-IDs der Crawl-Verschwendung durch Facetten zu.

Annehmen, ein kleiner Shop sei ausgenommen. Vielleicht gibt es kein Crawl-Budget-Problem, aber dünne/duplizierte Inhalte und Indexaufblähung bleiben möglich. Such-URLs unabhängig von der Größe blockieren.

Ecommerce-Site-Search — Spickzettel

Welche Kontrolle was tut

Anfrage → Aktion

Schnelle Fakten

• Googles wichtigste Crawl-Abfallkategorie: facettierte Navigation und Session-IDs; Ergebnisseiten folgen demselben Muster.
• noindex spart kein Crawl-Budget — Google ruft die Seite zuerst ab.
• Soft-404s (200 OK „keine Ergebnisse“) werden weiter gecrawlt und verschwenden Budget.
• Crawl-Budget ist meist ein Thema großer Websites; Indexaufblähung und Duplikate nicht.
• Der wertvolle Output der Site Search ist das Query-Log, nicht die Ergebnis-URL.

Tools für Ecommerce-Site-Search-SEO

• Google Analytics 4 — Site Search — der GA4-Bericht für Suchbegriffe erfasst Eingaben im Suchfeld (Suchparameter im Datenstream konfigurieren) und ist die primäre Quelle für interne Nachfragedaten.
• Interne Suchanalyse der Plattform — Shopify Search Analytics, Algolia-/Klevu-/Searchspring-Dashboards und Magentos Suchbegriffsbericht zeigen Null-Treffer, Top-Anfragen und Klickrate.
• Google Search Console — Bericht zur Seitenindexierung — Ausschlussbereiche beobachten, in denen Such-/Parameter-URLs anwachsen.
• GSC — Crawl Stats — prüfen, ob Googlebot Zeit auf /search oder ?q=-URLs verbringt.
• GSC — URL Inspection / Removals — Behandlung einer Such-URL bestätigen und bereits indexierte Seiten dringend bereinigen.
• Screaming Frog SEO Spider / Ahrefs Site Audit — intern verlinkte Such-URLs, Sitemap-Einträge, 200 bei leeren Ergebnissen sowie Soft-404- und Duplikatmuster finden.
• Keyword-Recherchetool (z. B. Ahrefs Keywords Explorer) — externe Nachfrage prüfen, bevor eine Seite gebaut wird.

Häufige Probleme bei interner Suche

Such-URLs bleiben nach einer robots.txt-Sperre indexiert

Wahrscheinliche Ursache: robots.txt verhindert das Crawling, garantiert aber keine Deindexierung. Google kann ein noindex auf der blockierten Seite nicht sehen. Lösung: Lassen Sie das Crawling vorübergehend zu und liefern Sie noindex aus, bis die URLs verschwunden sind; sperren Sie das Muster anschließend, um künftige Crawl-Verschwendung zu vermeiden. Bestätigen Sie den Zustand mit URL Inspection und nicht allein anhand einer site:-Abfrage.

Null-Treffer-Suchen erscheinen als Soft-404

Wahrscheinliche Ursache: Die Vorlage liefert auch ohne Produkte 200 OK. Lösung: echten 404 zurückgeben oder die nutzerfreundliche Recovery hinter einen bereits gesperrten Suchpfad legen. HTTP-Status getrennt von der sichtbaren Meldung prüfen.

Googlebot crawlt weiter neue Query-Kombinationen

Wahrscheinliche Ursache: Formulare, interne Links, Parameter oder uneinheitliche Pfadvarianten öffnen einen größeren URL-Raum, als die robots-Regel abdeckt. Lösung: reale Suchmuster aus Logs erfassen, crawlbare Links entfernen und eng geprüfte Disallow-Regeln aktualisieren. Bestätigen, dass wertvolle Produkt- und Kategorie-URLs erlaubt bleiben.

Eine beworbene Landingpage konkurriert mit ihrer alten Such-URL

Wahrscheinliche Ursache: Das rohe Suchergebnis ist nach dem Launch noch crawlbar oder intern verlinkt. Lösung: Navigation und Kontextlinks auf die saubere Landingpage zeigen lassen, den Suchraum kontrolliert halten und prüfen, dass die Landingpage selbst kanonisch ist.

Vereinfachte Beispiele für Site Search

Crawl-Eindämmung ohne widersprüchliche Direktive

User-facing search: /search?q=waterproof-boots
robots.txt:        Disallow: /search
page-level noindex: not relied on while the path is blocked
XML sitemap:       search URL omitted

Die Sperre betrifft künftiges Crawling. Ist die URL bereits indexiert, zunächst Crawling mit noindex erlauben und erst nach der Entfernung sperren.

Nachfrage auf eine echte Seite übertragen

Before: /search?q=gluten-free-protein-bars
After:  /collections/gluten-free-protein-bars/

Die saubere Collection erhält einen stabilen Titel, H1, hilfreichen Text, Breadcrumbs, kuratierte Produkte und interne Links. Die rohe Such-URL bleibt Teil des nicht indexierbaren Suchraums.

Anweisungen für die Analyse der Site Search

Interne Suchanfragen in Aktionen einteilen

Fügen Sie eine CSV mit Suchanfrage, Suchanzahl, Trefferanzahl und Conversions ein. Vor der Weitergabe an ein Modell müssen personenbezogene Daten entfernt werden.

You are reviewing ecommerce internal-search demand. For each supplied query, classify it
as: synonym/merchandising fix, zero-result inventory gap, possible curated landing page,
navigation problem, or noise. Explain the evidence from the supplied columns only. Do not
invent external search volume. Return a table and a separate list of items that require
external keyword validation before an indexable page is created.

Kontrollen für Such-URLs prüfen

Fügen Sie repräsentative Such-URLs, robots.txt, Response-Header und den relevanten HTML-Head ein.

Audit these internal-search URLs for crawl and index-control conflicts. For each URL,
report: robots.txt access, HTTP status, meta or X-Robots-Tag directive, canonical target,
internal-link source, and sitemap presence. Flag robots.txt + noindex conflicts and
200-status zero-result pages. Do not infer any value that is absent from the input.

Skripte zum Auffinden offengelegter Such-URLs

Response und robots-Datei einer repräsentativen URL prüfen

curl -I 'https://www.example.com/search?q=test'
curl -sS 'https://www.example.com/robots.txt'

Der erste Befehl bestätigt den echten HTTP-Status; der zweite vergleicht den exakten Pfad mit den ausgerollten Regeln. Ersetzen Sie die Adresse durch eine Website, die Sie kontrollieren.

Suchlinks in der aktuell gerenderten Seite finden

Führen Sie dies in der DevTools-Konsole auf einer repräsentativen Kategorie- oder Navigationsseite aus:

[...document.querySelectorAll('a[href]')]
  .map(a => a.href)
  .filter(href => /(?:\/search(?:\/|\?|$)|[?&](?:q|query|s)=)/i.test(href));

Jedes Ergebnis verdient Prüfung, weil gewöhnliche crawlbare Links den Such-URL-Raum offenlegen können, selbst wenn das Feature zunächst nur als Formular beginnt.

Anfragen an den Suchpfad in einem Access-Log-Auszug zählen

awk '$7 ~ /^\/search([/?]|$)/ {print $7}' access.log | sort | uniq -c | sort -nr

Passen Sie das Feld für den Request-Pfad an Ihr Logformat an. So werden tatsächlich gecrawlte Varianten sichtbar; Bots werden nur unterschieden, wenn die Eingabe bereits entsprechend gefiltert wurde.

Beweisen, dass die Suchkontrollen funktionieren

Crawl-Kontrolltest

Test: Repräsentative Such-URLs und wertvolle Kategorie-URLs im robots.txt Tester prüfen. Erwartet: Suchmuster sind gesperrt, Produkt- und Kategoriepfade bleiben erlaubt. Fehlerdeutung: Regel zu eng, zu breit oder nicht passend zu den ausgerollten URL-Mustern. Monitoring: direkt nach dem Deployment. Rollback: echte Katalog-URLs werden disallowed.

Status-Test für Null-Treffer

Test: Eine bekannte Anfrage ohne Treffer mit curl -I abrufen. Erwartet: echter 404, wenn die URL crawlbar ist, oder Bestätigung, dass der Suchpfad vollständig gesperrt ist. Fehlerdeutung: Crawlbare 200-Null-Treffer-Vorlage ist ein Soft-Error-Risiko. Monitoring: direkt nach dem Release. Rollback: gültige Suchen oder Produktseiten liefern Fehlerstatus.

Test der beworbenen Landingpage

Test: Neue kuratierte URL, Canonical, interne Links und das rohe Suchäquivalent prüfen. Erwartet: Die kuratierte Seite liefert 200, ist selbst kanonisch und erhält crawlbare Links; der rohe Suchraum bleibt kontrolliert. Fehlerdeutung: URL-Typen konkurrieren oder Seite ist verwaist. Monitoring: sofortige Technikchecks und anschließend Search-Console-Beobachtung nach erneutem Crawling. Rollback: Release öffnet einen unkontrollierten Query-URL-Raum.

Laufende Site-Search-Metriken

Crawl-Anteil von Such-URLs

Metrik: Anteil verifizierter Suchmaschinenanfragen an internen Such-URLs. Aussage: ob der kontrollierte URL-Raum weiter Crawl-Aktivität verbraucht. Erhebung: bot-verifizierte Serverlogs nach Pfad und Parameter gruppieren. Benchmark: Vorher-Basislinie erstellen und vermeidbare Such-URL-Anfragen senken, ohne wertvolles Katalog-Crawling zu unterdrücken. Taktung: nach Änderungen wöchentlich, danach monatlich.

Rate der Null-Treffer-Anfragen

Metrik: Interne Suchen ohne Produkte als Anteil aller internen Suchen. Aussage: wo Synonyme, Merchandising, Navigation oder Bestand Käufer scheitern lassen. Erhebung: Site-Search-Analytics nach normalisierter Anfrage segmentieren. Benchmark: Kategorien und Trend mit der eigenen Basislinie vergleichen; der Katalogmix macht ein allgemeines Ziel irreführend. Taktung: wöchentlich für Merchandising, monatlich für SEO-/Content-Planung.

Conversion mit Suchunterstützung

Metrik: Conversionrate und Umsatz für Sitzungen mit Site Search, wobei Query-Gruppen sichtbar bleiben. Aussage: ob das Feature Käufern hilft, Produkte zu finden, statt nur URLs zu erzeugen. Erhebung: Analytics-Ereignisse mit Transaktionen verbinden. Benchmark: Nicht-Such-Sitzungen und Vorperioden als Kontext verwenden, nicht als Kausalitätsbeweis. Taktung: monatlich und nach Relevanzänderungen.

Nachfrage auf dauerhafte Seiten übertragen

Metrik: Validierte interne Query-Themen, die zu kuratierten Seiten werden, plus organische Impressionen und Conversions dieser Seiten. Aussage: ob First-Party-Nachfrage zu nützlichem indexierbarem Bestand wird. Erhebung: Launchliste führen und mit Search Console und Analytics verbinden. Benchmark: jede Seite gegen ihren dokumentierten Nachfragenachweis prüfen. Taktung: vierteljährlich.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Texte

• Einsteigerleitfaden für technisches SEO — ordnet Crawl-Budget, Indexierung und die Kontrolle doppelter URLs in das Gesamtbild ein.
• Facettierte Navigation: Ein Leitfaden für SEOs — behandelt das engste Nachbarthema und dieselbe Logik: Rauschen sperren.
• Crawl-Budget: Alles, was Sie für SEO wissen müssen — erklärt, warum geringwertige URL-Räume wie Suchergebnisse den Crawl von wertvollen Seiten abziehen und wer sich tatsächlich damit befassen muss.
• Robots.txt und SEO: Alles, was Sie wissen müssen — erläutert das Werkzeug zur Eindämmung von Suchergebnisseiten und die dafür entscheidende Unterscheidung zwischen Crawling und Indexierung.

Meine Vorträge

• So funktioniert die Suche (SlideShare) — mein Überblick über Crawling, Rendering, Indexierung und Ranking. Dieses Denkmodell erklärt, warum Such-URLs als Crawl-Abfall behandelt werden. Mein dauerhafter Hinweis gilt: “This is my understanding of systems… not going to be 100% complete or accurate.” (Übersetzung) „Dies ist mein Verständnis der Systeme … es wird weder vollständig noch zu 100 % korrekt sein.“

Aus der Branche

• Was Crawl-Budget für den Googlebot bedeutet (Google Search Central) — Gary Illyes’ maßgebliche Liste geringwertiger URL-Kategorien, zu denen Suchergebnisseiten gehören.
• Crawl-Budget optimieren (Google Search Central) — erklärt, warum robots.txt hier noindex vorzuziehen ist, und warnt vor der Crawl-Verschwendung durch Soft-404s.
• Das Crawling von URLs mit facettierter Navigation verwalten (Google Search Central) — der Leitfaden für facettierte Navigation lässt sich direkt auf interne Such-URLs übertragen: mit robots.txt sperren, für leere Ergebnisse 404 zurückgeben und Canonical nur als schwächeres Werkzeug behandeln.
• Googles größte Crawling-Probleme (Search Engine Land) — Gary Illyes’ Aufschlüsselung der tatsächlichen Ursachen für übermäßiges Crawling; facettierte Navigation macht ungefähr die Hälfte der gemeldeten Probleme aus.
• Gary Illyes von Google warnt erneut vor Problemen mit URL-Parametern (Search Engine Journal) — die Warnung vor einer Vergrößerung des URL-Raums von “1000 URLs to a scorching 1 million” (Übersetzung) „1.000 URLs auf eine schwindelerregende Million“ gilt ebenso für Suchparameter.

Testen Sie sich selbst: Ecommerce-Site-Search-SEO

Fünf kurze Fragen dazu, wie interne Suchergebnisseiten mit SEO interagieren. Wählen Sie pro Frage eine Antwort und prüfen Sie anschließend das Ergebnis.

Änderungsprotokoll