URLs wirken oft banal. Ein paar Wörter, ein Fragezeichen, vielleicht noch ein Parameter hinten dran – fertig. Aber genau an solchen scheinbar kleinen Stellen entstehen manchmal die unangenehmsten SEO-Probleme. Vor allem dann, wenn Sonderzeichen im Spiel sind. Eckige Klammern, Pluszeichen, Leerzeichen, Prozentkodierung: Das klingt erst einmal nach trockenem Technikdetail. In der Praxis kann es aber darüber entscheiden, ob Suchmaschinen zwei Adressen als gleichwertig behandeln oder als unterschiedliche URLs crawlen, indexieren und bewerten.
Besonders interessant ist dabei ein Detail rund um eckige Klammern in URLs, also Zeichen wie [ und ]. Viele Websites verwenden solche Klammern in Query-Parametern, etwa bei Filtern in Online-Shops oder Listing-Seiten. Ein typisches Beispiel wäre:
example.com/category?filter[]=123
Technisch kann dieselbe URL aber auch kodiert auftauchen:
example.com/category?filter%5B%5D=123
Auf den ersten Blick würdest du wahrscheinlich sagen: Das ist doch dasselbe. Die eine Variante zeigt die Klammern direkt, die andere ersetzt sie durch ihre Prozentkodierung. Fertig. Genau diese Annahme ist aber heikel. Nach den URL-Standards sind diese beiden Varianten nicht automatisch identisch. Und genau hier wird es spannend – nicht nur für Entwickler, sondern auch für SEO-Verantwortliche.
Warum eckige Klammern in URLs komplizierter sind, als sie aussehen
Der Kern des Problems liegt in der Art, wie URLs standardisiert sind. In der technischen Spezifikation für URIs, genauer gesagt in RFC 3986, gibt es eine Gruppe sogenannter reservierter Zeichen. Dazu gehören unter anderem eckige Klammern [ ] und auch das Pluszeichen +. Reservierte Zeichen sind nicht einfach beliebige dekorative Zeichen. Sie können für bestimmte Zwecke vorgesehen sein oder von Anwendungen unterschiedlich interpretiert werden.
Und genau deshalb gilt: Wenn eine URL sich nur dadurch unterscheidet, dass ein reserviertes Zeichen einmal direkt vorkommt und einmal percent-encoded ist, dann sind diese beiden URLs laut Standard nicht zwingend äquivalent. Etwas vereinfacht gesagt: Aus [ wird zwar %5B, aus ] wird %5D, aber diese Umwandlung darf bei reservierten Zeichen nicht blind als Normalisierung verstanden werden.
Das ist so ein Punkt, bei dem man als SEO schnell ins Stolpern kommt. Aus meiner Erfahrung denkt man bei URL-Encoding oft an eine rein technische Schreibweise. Ein bisschen wie Groß- und Kleinschreibung bei Hex-Werten: %5B und %5b sind tatsächlich gleich. Aber der Unterschied zwischen einem echten reservierten Zeichen und seinem kodierten Gegenstück kann die Interpretation verändern.
Sehr schön sieht man das an einem einfachen JavaScript-Vergleich:
new URL(‚https://example.com/category?filter[]=123‘).href === new URL(‚https://example.com/category?filter%5B%5D=123‘).href
Das Ergebnis ist false. Also nein, diese beiden URLs werden nicht als dieselbe href-Variante normalisiert. Für Menschen sehen sie fast gleich aus. Für Maschinen eben nicht unbedingt.
Das wirkt zunächst kleinlich, fast pedantisch. Aber das Web ist voll von solchen Details. Und Suchmaschinen müssen mit diesem Durcheinander umgehen: technisch korrekte URLs, technisch fragwürdige URLs, alte CMS-Konventionen, Frameworks, Weiterleitungen, Canonicals, Parameter, Tracking-Anhängsel und Server, die alles irgendwie akzeptieren. Manchmal erstaunlich robust, manchmal eben nicht.
Google kann vieles abfangen – aber darauf solltest du dich nicht blind verlassen
Die beruhigende Seite zuerst: Google dürfte mit solchen Fällen heute in vielen Situationen umgehen können. Wenn zwei URL-Varianten gecrawlt werden und am Ende exakt denselben Inhalt ausliefern, kann Google sie womöglich zusammenführen, also deduplizieren, und sich eine bevorzugte Variante aussuchen. In der Praxis passiert das ständig. Das Web ist chaotisch, und Suchmaschinen wären ziemlich nutzlos, wenn sie nur perfekt normierte URLs verarbeiten könnten.
Aber, und das ist der wichtigere Punkt: Nur weil Google etwas meistens versteht, heißt das nicht, dass du es sauber so bauen solltest.
Wenn Google beide Versionen findet – also zum Beispiel:
/category?filter[]=123
und
/category?filter%5B%5D=123
dann kann es sein, dass beide gecrawlt werden. Wenn beide dieselben Inhalte zeigen, kann Google sie zusammenlegen. Vielleicht sogar anhand sehr genauer Inhaltsvergleiche. Trotzdem erzeugst du damit unnötige Mehrdeutigkeit. Und Mehrdeutigkeit ist bei SEO nie dein Freund.
Ich habe solche Fälle in Projekten schon in ähnlicher Form gesehen, meistens nicht mit eckigen Klammern, sondern mit Parametern, Slashes, Groß- und Kleinschreibung oder Leerzeichen. Das Problem ist selten, dass sofort alles explodiert. Viel häufiger passiert etwas Langweiligeres, aber langfristig Ärgerliches: Crawling wird ineffizienter, Canonicals widersprechen internen Links, Sitemaps enthalten eine andere Variante als strukturierte Daten, und irgendwann fragst du dich, warum bestimmte Seiten nicht so stabil indexiert werden, wie sie sollten.
Genau deshalb lautet die pragmatische Empfehlung: Entscheide dich für eine URL-Variante und verwende sie konsequent.
Das betrifft nicht nur sichtbare Links auf der Website. Es betrifft besonders:
interne Links, rel=canonical, XML-Sitemaps, strukturierte Daten, hreflang-Angaben, Pagination, Filter-Links und alles, was URLs maschinenlesbar ausgibt.
Wenn du in internen Links die nicht kodierte Variante nutzt, im Canonical aber die kodierte Variante, sendest du gemischte Signale. Google kann das eventuell auflösen. Andere Crawler vielleicht nicht. Und selbst Google muss dafür zusätzliche Arbeit leisten. Es ist ein bisschen so, als würdest du einem Zusteller drei Schreibweisen derselben Adresse geben und hoffen, dass er schon merkt, welches Haus gemeint ist. Meistens klappt es. Professionell ist es trotzdem nicht.
Bestehende Websites: Nicht sofort in Panik geraten
Interessant ist der Fall einer Website, die bereits überall die technisch ungünstige Variante mit direkten eckigen Klammern verwendet. Also etwa ?filter[]=123. Streng nach RFC 3986 ist das problematisch, denn eckige Klammern sind in URLs nur sehr eingeschränkt vorgesehen, insbesondere im Hostnamen zur Darstellung von IPv6-Adressen. In Query-Parametern sind sie in dieser Rohform nicht die saubere Variante.
Trotzdem heißt das nicht automatisch, dass eine solche Website aus dem Index fällt oder akut kaputt ist. Das Web ist, nun ja, nicht gerade ein Museum technischer Reinheit. Viele Dinge funktionieren, obwohl sie formal nicht schön sind. Browser kodieren solche Zeichen oft automatisch, Server nehmen sie trotzdem an, Frameworks interpretieren sie auf ihre eigene Weise. Manchmal benehmen sich Server tatsächlich wie Katzen: Du weißt ungefähr, was sie tun sollten, aber garantiert ist es nicht.
Wenn eine bestehende Website seit Jahren mit solchen Parametern arbeitet und stabil indexiert wird, wäre eine überhastete Umstellung nicht unbedingt klug. Gerade bei großen Shops oder Plattformen kann eine Änderung an URL-Parametern enorme Folgen haben. Du musst Weiterleitungen prüfen, Canonicals anpassen, interne Links ändern, Tracking kontrollieren, Sitemaps erneuern, Cache-Regeln testen. Da ist schnell mehr kaputtgemacht als repariert.
Ich würde so eine Situation nüchtern bewerten: Läuft alles stabil? Gibt es Indexierungsprobleme? Werden doppelte URL-Varianten gecrawlt? Tauchen beide Versionen in Logs auf? Gibt es Canonical-Konflikte? Wenn ja, dann lohnt sich ein Bereinigungsprojekt. Wenn nein, kann man die bestehende Struktur unter Umständen beibehalten, aber mit besonderer Sorgfalt und Monitoring.
Für eine neue Website wäre die Empfehlung allerdings klarer: Baue URLs nicht neu mit rohen eckigen Klammern in Query-Parametern auf. Nutze eine saubere, konsistente und standardkonforme Variante. Das erspart dir später Diskussionen, Sonderfälle und unnötige technische Schulden.
Der eigentliche SEO-Punkt: Konsistenz schlägt Hoffnung
Der wichtigste Gedanke bei dieser ganzen Diskussion ist nicht „Google hat ein Problem mit eckigen Klammern“. So einfach ist es nicht. Eher geht es darum, dass Internetstandards sehr genau sind und dass kleine Unterschiede in URLs echte Unterschiede sein können. Google scheint heute mit vielen dieser Fälle umgehen zu können, auch wenn es in der Vergangenheit intern offenbar Schwierigkeiten mit solchen Sonderzeichen gab. Diese Probleme liegen wohl lange zurück. Trotzdem bleibt die Grundregel bestehen: Je klarer deine URL-Signale, desto weniger musst du hoffen.
Das betrifft übrigens nicht nur eckige Klammern. Ähnliche Vorsicht gilt bei Leerzeichen, Pluszeichen und %20. Besonders tückisch ist, dass die Bedeutung davon abhängen kann, wo das Zeichen steht: im Pfad, in der Query-String-Komponente oder in einem anderen URL-Bestandteil. Ein Pluszeichen kann in einem Kontext ein echtes Plus sein, in einem anderen als Leerzeichen interpretiert werden. Solche Dinge sind nicht intuitiv, und genau deshalb schleichen sich Fehler ein.
Ein praktisches Beispiel: Wenn du einen Filter für rote Schuhe hast, könnte ein System daraus so etwas machen:
/shop?color=red+shoes
Ein anderes System schreibt:
/shop?color=red%20shoes
Ein drittes nutzt vielleicht:
/shop/red-shoes/
Alle drei Varianten können für Menschen dieselbe Idee transportieren. Technisch sind sie aber nicht automatisch dasselbe. Wenn dein System mehrere Varianten erzeugt, musst du sehr sauber steuern, welche gecrawlt werden sollen, welche canonicalisiert werden und welche gar nicht erst intern verlinkt werden.
Was du konkret prüfen solltest
Wenn du auf deiner Website URLs mit eckigen Klammern, Pluszeichen oder anderen Sonderzeichen verwendest, würde ich nicht als Erstes blind alles ändern. Ich würde zuerst schauen, wie groß das Problem wirklich ist.
Ein guter Startpunkt sind Server-Logs. Dort siehst du, welche URL-Varianten tatsächlich von Suchmaschinen-Crawlern abgerufen werden. Wenn du feststellst, dass sowohl ?filter[]=123 als auch ?filter%5B%5D=123 regelmäßig gecrawlt werden, hast du zumindest ein Signal, dass die Varianten in der Praxis parallel existieren. Dann lohnt sich ein genauer Blick.
Danach solltest du prüfen, was deine internen Links ausgeben. Viele Theme-Templates, Filtermodule oder JavaScript-Komponenten erzeugen URLs automatisch. Da verstecken sich solche Inkonsistenzen gern. Besonders gemein: Der sichtbare Link im Browser kann anders aussehen als das, was im HTML steht oder was durch JavaScript nachträglich gesetzt wird.
Dann kommt der Canonical. Wenn die Seite unter beiden URL-Varianten erreichbar ist, sollte der Canonical eindeutig auf deine bevorzugte Version zeigen. Aber bitte nicht nur irgendwie. Er sollte zu dem passen, was du intern verlinkst. Ein Canonical ist kein Besen, mit dem du jede Unordnung unter den Teppich kehrst. Er ist ein Signal – stark, aber nicht magisch.
Auch XML-Sitemaps verdienen Aufmerksamkeit. In Sitemaps sollten nur die bevorzugten, kanonischen URLs stehen. Wenn dort kodierte Varianten stehen, intern aber unkodierte Links verwendet werden, ist das wieder so ein kleines „Warum machen wir es uns schwer?“-Problem.
Und schließlich: strukturierte Daten. Viele vergessen, dass darin ebenfalls URLs vorkommen können, etwa in url, mainEntityOfPage, image oder anderen Properties. Wenn die strukturierten Daten eine andere URL-Form ausgeben als der Canonical, ist das kein Weltuntergang, aber eben ein weiterer kleiner Widerspruch.
Andere Crawler können weniger tolerant sein
Ein Punkt wird in SEO-Diskussionen oft unterschätzt: Google ist nicht der einzige Crawler, der wichtig sein kann. Je nach Website können auch Bing, interne Suchsysteme, Preisvergleichsportale, Social-Media-Bots, KI-Crawler, Monitoring-Tools, Affiliate-Systeme oder spezialisierte Indexer relevant sein. Und nicht alle verhalten sich so robust oder so ausgefeilt wie Google.
Wenn Google zwei URL-Varianten erkennt und sauber zusammenführt, heißt das noch lange nicht, dass andere Systeme das ebenfalls tun. Manche Bots sind streng nach Standard. Andere sind schlampig. Wieder andere dekodieren zu viel oder zu wenig. Das klingt banal, kann aber in der Praxis nerven. Zum Beispiel, wenn ein Social Preview Tool die falsche URL speichert, ein Merchant-System doppelte Produkte erkennt oder ein externer Crawler plötzlich Tausende Parameter-Varianten meldet.
Gerade deshalb ist technische Sauberkeit nicht nur ein Google-Thema. Sie macht dein gesamtes Ökosystem stabiler. Wenn du eine URL-Variante definierst und konsequent nutzt, reduzierst du nicht nur SEO-Risiken, sondern auch Fehlerquellen in Reporting, Tracking und Datenfeeds.
Technisch ungültig heißt nicht automatisch praktisch kaputt
Hier muss man ein bisschen differenzieren. Die rohe Verwendung von [] in URLs kann nach Standard problematisch sein. Trotzdem funktioniert sie im Web häufig. Manche Frameworks nutzen diese Schreibweise sogar traditionell, um Array-Parameter abzubilden, etwa filter[]=123 oder category[]=shoes. Entwickler kennen das aus verschiedenen Backend-Umgebungen. Der Server versteht es, die Anwendung versteht es, der Browser macht meistens mit.
Das ist der Grund, warum man nicht sofort dramatisieren sollte. Es gibt einen Unterschied zwischen technisch ideal und praktisch akzeptiert. SEO lebt oft genau in dieser Grauzone. Eine Website kann mit nicht perfekten URLs sehr gut ranken. Eine andere kann an winzigen Inkonsistenzen leiden, weil sie ohnehin schon viele Parameter, dünne Inhalte und Duplicate-Content-Muster hat.
Mein Bauchgefühl dazu: Wenn deine Website groß, parameterlastig und crawlbudget-sensibel ist, solltest du solche Themen ernster nehmen. Wenn du eine kleine Website hast, auf der ein paar Filter-URLs vorkommen, ist es wahrscheinlich weniger dramatisch. Aber auch dann gilt: Neu bauen würde ich es sauber.
Die sauberste Lösung: Eine Regel, überall dieselbe Umsetzung
Am Ende kommst du immer wieder zur gleichen, etwas unspektakulären Empfehlung zurück: Wähle eine kanonische URL-Schreibweise und ziehe sie konsequent durch.
Das klingt fast zu einfach. Ist es aber nicht, weil URLs an sehr vielen Stellen entstehen. Nicht nur im CMS. Auch im Frontend, im Tag Manager, in Facettennavigationen, in Tracking-Parametern, in Exporten, in Produktfeeds, in hreflang-Generatoren, in Pagination-Elementen, in APIs und manchmal sogar in E-Mail-Templates.
Wenn du eckige Klammern brauchst, solltest du prüfen, ob sie wirklich nötig sind. Oft lässt sich ein Parameter auch anders gestalten. Statt:
?filter[]=123
könnte man beispielsweise mit einer klareren Parameterstruktur arbeiten:
?filter=123
oder, wenn mehrere Werte nötig sind:
?filter=123,456
oder:
?filter=123&filter=456
Welche Variante sinnvoll ist, hängt vom System ab. Wichtig ist nicht, dass es eine einzige perfekte Lösung für alle gibt. Wichtig ist, dass du nicht mehrere Schreibweisen parallel erzeugst und dann darauf hoffst, dass Suchmaschinen schon alles richtig einsortieren.
Falls du bereits beide Varianten im Umlauf hast, kann eine Bereinigung unterschiedlich aussehen. Manchmal reicht ein konsistenter Canonical plus saubere interne Links. Manchmal sind 301-Weiterleitungen sinnvoll. Bei Query-Parametern ist das allerdings etwas heikel, weil Weiterleitungsregeln schnell unerwartete Nebenwirkungen haben können. Da würde ich immer erst testen – wirklich testen, nicht nur kurz im Browser anklicken.
Bei sehr großen Websites lohnt sich außerdem ein Crawling mit mehreren Tools. Nicht jedes Tool verarbeitet URLs gleich. Wenn ein Crawler die Varianten getrennt ausweist, bekommst du ein Gefühl dafür, welche Muster existieren. Ergänzend dazu sind Logfiles Gold wert, weil sie zeigen, was Suchmaschinen tatsächlich abrufen, nicht nur was ein Tool theoretisch findet.
Was du daraus mitnehmen solltest
Eckige Klammern in URLs sind ein schönes Beispiel dafür, wie klein technische SEO manchmal wird. Ein Zeichen, zwei Schreibweisen, und plötzlich geht es um Standards, Crawling, Canonicals und Indexierung. Man kann darüber lächeln. Aber genau solche Kleinigkeiten summieren sich auf Websites mit vielen Parametern sehr schnell.
Die wichtigste Erkenntnis ist: ?filter[]=123 und ?filter%5B%5D=123 sind nach URL-Standard nicht automatisch dieselbe URL. Google kann solche Fälle wahrscheinlich oft verarbeiten, insbesondere wenn beide Varianten denselben Inhalt ausliefern. Trotzdem solltest du dich nicht darauf verlassen, dass jede Suchmaschine, jeder Bot und jedes Tool dieselbe Logik verwendet.
Wenn du eine bestehende Website mit rohen eckigen Klammern hast und alles stabil läuft, musst du nicht reflexartig umbauen. Aber du solltest die Signale sauber halten: interne Links, Canonicals, Sitemaps und strukturierte Daten sollten dieselbe bevorzugte Variante verwenden. Wenn du eine neue Website planst, würde ich solche URL-Muster gar nicht erst einführen.
Unterm Strich ist das kein Grund zur Panik, aber ein guter Anlass für technische Hygiene. Konsistente URLs sind langweilig – und genau das ist ihr Vorteil. Sie geben Suchmaschinen weniger Rätsel auf, verursachen weniger doppelte Crawls und machen dir später weniger Arbeit. Und wenn man ehrlich ist: In SEO gibt es schon genug Unsicherheit. Da muss man sie nicht auch noch in den eigenen URL-Parametern verstecken.
