Google hat einen Draft für einen neuen HTTP-Standard veröffentlicht (IETF-Specification, MDN). Und das Beste: Chrome unterstützt das Ganze schon seit über einem Jahr.
Die Idee löst ein Problem, das seit Jahrzehnten absurd viele Ressourcen frisst – bei Browsern, CDNs, Search Engines und in unzähligen SEO-Tickets.
Die Frage war immer:
Wie werde ich URL-Parameter los, die das Ergebnis gar nicht verändern?
Zum Beispiel:
Wenn eine URL solche Parameter enthält, sollte der Browser oder das CDN trotzdem die bereits gecachte Variante ohne Parameter verwenden können.
Denn technisch ist:
Oft exakt dieselbe Ressource beziehungsweise das gleiche HTML wie:
Bisher mussten Browser, CDNs und Suchmaschinen das aber erst mühsam herausfinden.
Die Lösung heißt:
Ein HTTP-Header mit sauberer Ein-/Ausschluss-Logik für Query-Parameter.
Zum Beispiel:
Damit signalisiert der Server:
Diese Parameter verändern die Antwort nicht.
Browser, CDNs – und perspektivisch vielleicht auch Google – dürfen diese Varianten also als identisch behandeln.
Aus:
Wird effektiv dieselbe Ressource wie:
Oder einfach:
Für Browser reduziert das Ladezeiten. Für CDNs reduziert es Cache-Fragmentierung und Kosten. Und für Search Engines könnte es langfristig ein starkes Signal gegen technische Duplikate werden.
Harry Roberts erklärt die praktische Verwendung des No-Vary-Search-Headers hervorragend.
Unterstützt Google Search das schon?
Sicher wissen wir es nicht. Chrome kann es jedenfalls bereits verarbeiten. Der Web Rendering Service theoretisch also ebenfalls.
Aber: Für Google wäre das crawlerseitig ein größerer Paradigmenwechsel.
Denn plötzlich müsste die Crawl-Infrastruktur prüfen:
Wurde eine andere Variante dieser Ressource bereits gecrawlt und ist noch gültig gecached?
Das klingt trivial. Ist es aber auf Google-Skala nicht.
Dazu kommt: Das eigentliche Problem für Google ist heute vermutlich weniger technischer Duplicate Content als massenhafter Spam.
Trotzdem: Der Ansatz ist elegant. Und angesichts eines explodierenden Web-Korpus wäre ich nicht überrascht, wenn genau solche Mechanismen wichtiger würden.
Wichtig ist auch: Das löst keine kaputten URL-Konstrukte wie:
Solche Dinge sollten weiterhin besser gar nicht existieren. In vielen Fällen wäre POST statt GET die sauberere Lösung.
Trotzdem freue ich mich darauf, das zu implementieren.
Allein schon als späte Genugtuung für 15 Jahre Tickets wie:
- „Können wir Tracking-Parameter bitte nicht intern verlinken?“ (auch wenn intern verlinkte utm-Parameter weiterhin die Session-Attribution Deiner Webanalyse kaputt machen und daher ein no go bleiben)
- „Warum sind Parameter nicht sortiert?“
- „Warum explodiert unser Cache?“
- „Warum verarbeitet der Server Parameter so langsam?“
Mein neuer Default:
Natürlich ersetzt das keine saubere URL-Architektur. Man sollte weiterhin prüfen, ob ein Parameter überhaupt nötig ist.
Und der Nutzen ist aktuell vor allem konkret, wenn:
- intensiv mit der Speculation Rules API gearbeitet wird
- CDN-Cache-Varianten teuer werden
- Und für Google Search könnte daraus irgendwann ein sehr interessantes Crawl- und Dedupe-Signal werden.
Ich liebe es, wenn an gut abgehangener Technik wie HTTP-Headern nach Jahrzehnten nochmal sinnvoll weitergebaut wird.
Noch ist das Theorie. Aber eine verdammt spannende.