Wir haben einen CrUX MCP Server gebaut — Core Web Vitals Felddaten direkt in Claude Code

01Das PSI-Paradox

Jede SEO-Agentur kennt die Situation: PageSpeed Insights zeigt 94 Punkte auf Mobile — alles grün. Zwei Wochen später meldet Search Console eine Core-Web-Vitals-Warnung für dieselbe Seite.

Kein Fehler. Kein Bug. Das ist der Unterschied zwischen Lab-Daten und Felddaten.

PageSpeed Insights ist unverzichtbar für Diagnose und Optimierung — aber es ist nicht das, was Google für den Ranking-Algorithmus heranzieht. Dafür braucht man CrUX.

02Was CrUX wirklich misst

CrUX (Chrome User Experience Report) ist Googles Sammlung von Felddaten echter Chrome-Nutzer (Real-User-Monitoring, RUM) — aggregiert über 28 Tage — mit denen sich Core Web Vitals auf URL- oder Origin-Ebene bewerten lassen. Wer Chrome nutzt und Performance-Reporting aktiviert hat, trägt automatisch dazu bei, ohne dass personenbezogene Daten erhoben werden.

Drei Eigenschaften machen CrUX für SEO relevant:

• 28-Tage-Rolling-Window. Der aktuelle Datensatz umfasst immer die letzten 28 Tage. Kein Stichtag, kein Monatsbericht — rollend, kontinuierlich.
• p75 — nicht der Durchschnitt. Google bewertet nicht den Median, sondern das 75. Perzentil: 75 % aller Nutzer erleben diese Metrik besser oder gleich, 25 % schlechter. Wer das Schlussviertel ignoriert, bekommt eine falsch-positive Beurteilung.
• Formfaktor-Split. CrUX kann nach Mobile, Desktop und Tablet getrennt abgefragt werden. Das aggregierte „ALL“ verbirgt oft, dass mobile und Desktop-Nutzer komplett verschiedene Probleme haben.

Die fünf CrUX-Metriken:

LCP, CLS und INP sind die drei Core Web Vitals — alle drei müssen „gut“ sein, damit eine Origin CWV besteht.

03Der Stack

Der MCP-Server ist in Python geschrieben, läuft lokal und ist in Claude Code eingebunden. Kernkomponente ist das FastMCP-Framework — dasselbe wie beim Keyword- und GSC-Server.

Ein typischer Aufruf:

seo_crux_query("https://example.com", form_factor="PHONE")

Rückgabe: p75-Werte für alle verfügbaren Metriken, gut/neutral/schlecht-Rating, Histogramm-Buckets (Anteil der Nutzer in jedem Bucket) und ein cwv_pass-Flag. Fehlt der Origin genug Traffic, gibt die API 404 zurück — die ehrlichste Antwort, die CrUX geben kann.

04Zwei Brands, ein Muster

Zwei eCommerce-Brands, beide mobile-heavy. Beide mit CWV-Fail. Und beide mit völlig verschiedenen Problemen — je nach Gerät.

Brand A (Snapshot · 2026-05-30 → 2026-06-26)

Das aggregierte „ALL“ zeigt LCP 2.891 ms — Needs Improvement. Unauffällig. Erst der Formfaktor-Split zeigt: Mobile scheitert an LCP, Desktop scheitert an CLS — zwei verschiedene Ursachen, zwei verschiedene Optimierungsrichtungen.

Brand B (Snapshot · 2026-05-30 → 2026-06-26)

Brand B ist signifikant kritischer: LCP, INP und TTFB sind auf Mobile schlecht. Desktop besteht wegen CLS 0,39 ebenfalls nicht. Die TTFB von über 3 Sekunden auf Mobile deutet auf ein fundamentales Servergeschwindigkeits- oder CDN-Problem hin — alle anderen Metriken leiden darunter als Folge.

05Die Geschichte dahinter

Ein Snapshot zeigt den Ist-Stand. CrUX-History zeigt, warum der Ist-Stand so ist.

Brand A — Erholung mit stiller Regression

Zwischen Dezember und April wurde LCP um 33 % verbessert — von schlecht auf nahezu gut. Seit April driftet der Wert zurück, ohne erkennbares Ereignis. Die klassische stille Regression: kein Deployment, keine sichtbare Änderung — aber irgendwas hat sich geändert.

Brand B — Kein Recovery in Sicht

Brand B war im Dezember noch im neutralen Bereich — 25 Wochen später ist LCP schlecht und wird schlechter. Die TTFB-History zeigt dasselbe Muster: von 2.259 ms im Dezember auf 3.052 ms im Mai. Kein Gegensteuern erkennbar.

06Was Google für das Ranking wirklich sieht

Der CWV-Bericht in Google Search Console ist nicht eine Annäherung an CrUX-Daten — er ist CrUX-Daten. Core Web Vitals sind kein alleiniger Ranking-Faktor. Sie sind aber ein messbarer Bestandteil der Page Experience — und der einzige, den Google mit echten Nutzerdaten belegt.

Drei Konsequenzen für die Praxis:

• Der 28-Tage-Lag ist real. Eine Optimierung, die heute live geht, braucht 28 Tage, um vollständig im CrUX-Fenster sichtbar zu werden. Eine PSI-Verbesserung ist sofort messbar; eine CWV-Verbesserung in Search Console erscheint erst nach einem Monat vollständig.
• CWV ist binär. Entweder alle drei Metriken (LCP, CLS, INP) sind „gut“ — oder die Origin gilt als nicht bestanden. neutral in einer Metrik = Fail. Es gibt kein „fast gut genug“.
• Der Formfaktor zählt. Googles Mobile-First-Indexierung bedeutet: Mobile-CrUX-Daten haben das höchste Gewicht. Brand A und Brand B scheitern primär wegen ihrer Mobile-Werte — auch wenn Desktop partiell besser abschneidet.

07Im Kundenalltag

Der CrUX-Server ist das neunte Modul in unserem MCP-Stack. Wann er vor PSI kommt, wann PSI vor CrUX:

1. Search Console meldet CWV-Warnung → CrUX zuerst: Was sieht Google aktuell? Welche Metrik, welches Gerät?
2. CrUX nach Formfaktor aufschlüsseln → Mobile und Desktop getrennt abfragen. Die aggregierte Ansicht ist nicht falsch, sie ist nur zu grob.
3. CrUX-History abfragen → Wann hat sich das Problem entwickelt? War es ein Deployment-Ereignis oder eine stille Regression?
4. PSI für die Ursachenanalyse → Was genau verursacht das LCP-Problem? Welches Element? Welcher Ressourcentyp? Das beantwortet PSI sofort, CrUX nicht.
5. Fix deployen, PSI-Verbesserung verifizieren → Sofortige Rückmeldung aus dem Lab.
6. 28 Tage abwarten, CrUX erneut abfragen → Hat sich der Ranking-Signal verbessert?

Das Modul-Set

08Warum es zählt