Technisches SEO, das AI Overviews, Headless-Rebuilds und dein nächstes Algorithm-Update übersteht.

Technisches SEO ist die Schicht der Arbeit, die entscheidet, ob Suchmaschinen und KI-Assistenten deine Seiten crawlen, rendern und vertrauen können — bevor Content oder Backlinks überhaupt eine Rolle spielen. Es umfasst HTTP-Verhalten, HTML-Semantik, strukturierte Daten, hreflang, Kanonisierung, Core Web Vitals und JavaScript-Rendering. Mach es falsch und der Rest deiner Investition ist Ballast.

2026 hat sich die Definition erweitert. Zwei Veränderungen haben das vorangetrieben. Erstens sitzen AI Overviews und ChatGPT-gesteuerte Suche jetzt zwischen den meisten Nutzern und den eigentlichen Seiten, was bedeutet, dass Zitierbarkeit genauso wichtig ist wie Ranking. Zweitens ist die Standard-Website nicht mehr eine WordPress-Installation — es ist irgendeine Form von Headless-Frontend, das Content aus Sanity, Strapi, Payload, Storyblok, Contentful oder einem Headless WordPress Backend zieht. Jeder dieser Stacks führt seine eigenen technischen SEO-Fehlermodi ein, die das alte Playbook nicht abdeckt.

Meine Arbeitsdefinition für Clients 2026: Technisches SEO ist alles, das ein Lighthouse-Lauf, ein Search Console-Crawl-Report, ein AI Overview-Zitierbarkeitscheck und ein Schema-Validator bemerken — über jedes Locale, jedes Template, jeden Render-Pfad hinweg. Wenn eines dieser vier Signale auf einer repräsentativen URL fehlschlägt, startet das Engagement dort.

Bei einer Headless- oder Jamstack-Website kontrolliert dein Frontend-Framework das Rendering und dein CMS kontrolliert den Inhalt — und SEO kann in die Lücke zwischen ihnen fallen. Das klassische WordPress + Yoast-Modell ging von einem Server, einem Renderer, einer Rules Engine aus. Wenn du Inhalte aus WordPress in Next.js oder Astro ziehst, ererbst du automatisch nichts davon.

Headless WordPress kombiniert mit Next.js oder Astro

Die häufigste Konfiguration, die wir 2026 sehen: WP REST oder WPGraphQL exponieren Beiträge und Seiten, Next.js App Router oder Astro pullen sie zur Build-Zeit oder via ISR. Die Gewinne sind real — Seiten werden ohne Plugin-Bloat ausgeliefert, Core Web Vitals bleiben einfach grün, und Redakteure behalten einen vertrauten Admin. Die Fallstricke sind auch real. Yoast-Canonicals und Meta-Beschreibungen müssen über die API-Grenze transportiert werden; in WordPress definierte Weiterleitungen müssen in vercel.json oder Netlify _redirects landen; Sitemaps müssen meist auf dem Frontend-Build regeneriert werden, nicht auf der WordPress-Seite; und Search-Console-Verifizierung muss auf der öffentlichen Domain passieren, nicht auf der wp-admin-Domain.

Reine moderne Stacks

Ein Next.js + Sanity-Build, ein Astro + Storyblok-Build, ein Nuxt + Strapi-Build, ein Next.js + Payload-Build — alle umgehen WordPress vollständig. Die Technical-SEO-Arbeit verschiebt sich darauf, sicherzustellen, dass dein CMS-Schema die SEO-Felder modelliert, die das Frontend braucht (Canonical Override, Redirect Map, Hreflang Group, Schema-Extension JSON), und sicherzustellen, dass On-Demand-Revalidierung auslöst, wenn Inhalte sich ändern. ISR-Cache-Poisoning ist der stille Killer — eine Seite wird Stunden nach der Veröffentlichung veraltet ausgeliefert, weil revalidatePath nie verdrahtet wurde.

Was bricht eigentlich zuerst

Bei etwa 200 Headless-Audits, die wir durchgeführt haben, ist das einzelne häufigste produktionsabbrechende Problem ein Canonical-Konflikt — das Frontend emittiert eine Canonical-URL, während die CMS-Metadaten oder die Sitemap eine andere emittieren. Google wählt eine, fast immer nicht die, die du wolltest, und die falsche URL landet im Index. Wir fangen das mit einem Build-Zeit-Linter auf, der canonical-from-template gegen canonical-stored-in-CMS für eine Stichprobe von Seiten vergleicht und den Build bei Nichtübereinstimmung abbricht.

WordPress gibt dir die meiste Plugin-Feuerkraft und die meisten Wege, dich selbst zu schießen. Das Technical-SEO-Playbook auf einer klassischen WordPress-Website dreht sich meist um Subtraktion — doppelte Canonicals entfernen, Schema-Konflikte zwischen Yoast und RankMath und einem dritten Plugin, das niemand installiert haben erinnert, beruhigen, Page Builder zähmen, die 2 MB CSS mitbringen, und Weiterleitungsketten räumen, die sich über acht Jahre aufgebaut haben.

Der Standard-Stack, den wir 2026 empfehlen: ein einzelnes SEO-Plugin (RankMath oder Yoast, niemals beide), ein verwalteter Host mit ordentlichem Edge-Caching (Cloudways, Kinsta, WP Engine), Bricks Builder für Neuentwicklungen, wo Performance zählt, oder natives Gutenberg mit Kadence oder Blocksy, ein Redirect-Manager, der in ein tragbares Format exportiert, und Perfmatters oder FlyingPress für Asset-Cleanup. Die Audit-Arbeit besteht darin, herauszufinden, welche dieser Entscheidungen auf deiner Website anders getroffen wurde, und die Konsequenzen rückgängig zu machen.

Auf der Headless-Seite verlagert sich die Arbeit von der Subtraktion zur Konstruktion. Es gibt kein Yoast, also muss Meta-Clamping selbst gebaut werden. Es gibt kein Plugin-Schema, also muss JSON-LD templatet werden. Es gibt keine eingebaute Sitemap, also muss sie generiert und gestreamt werden. Das Volumen an Code, das wir zu einem Headless-Projekt für SEO hinzufügen, ist normalerweise drei- bis fünfmal so groß wie das, was eine WordPress-Site dir kostenlos bereits bietet — aber dieser Code ist dein Eigentum, versionskontrolliert, testbar und bricht nicht beim nächsten Plugin-Update.

GEO und AEO sind die Namen für zwei verschiedene Arten, wie AI-Features Suchtraffic abzweigen. AEO (Answer Engine Optimisation) ist der ältere Begriff — er deckt Google-Features wie Featured Snippets, People Also Ask und Knowledge Panels ab, die einen Ausschnitt von deiner Seite extrahieren und ihn als Antwort anzeigen. GEO (Generative Engine Optimisation) ist der neuere Begriff — Optimierung für AI Overviews, ChatGPT Search, Perplexity und Bing Copilot, wo der Assistent einen Absatz generiert und deine Seite als Quelle zitiert.

Was das strukturell bedeutet

Beide Oberflächen wollen dasselbe: einen zitierbar gemachten Absatz. Die strukturellen Regeln, die über alle hinweg funktionieren, sind gleich. Nutze eine Frage als deine H2, keine Topic-Bezeichnung. Platziere die Antwort in den ersten ein oder zwei Sätzen nach der Überschrift. Halte die Antwort unter 250 Wörtern. Stelle sicher, dass die Antwort serverseitig gerendert wird, nicht in einer JavaScript-Komponente, die nach dem Seitenladevorgang hydratisiert. AI-Crawler und Google-Extractoren führen meistens kein JavaScript aus — wenn deine Antwort JS brauchst, um angezeigt zu werden, bist du unsichtbar.

Wo GEO von AEO abweicht

Drei Dinge sind für GEO speziell wichtiger. Entity Authority — Google und die LLMs bauen einen Graphen auf, wer über was sprechen darf, und unverlinkte Brand Mentions speisen ihn. Schema mit about- und mentions-Arrays — sie machen deine Seite als Teil eines Entity-Graphen analysierbar statt als Textwand. Und llms.txt — ein emerging Standard-File unter /llms.txt, das AI-Tools eine kuratierte Karte deiner Site gibt, genauso wie robots.txt und sitemap.xml Search Crawlern helfen. Wir deployen llms.txt auf jeder Site, die wir bauen, und aktualisieren es, wenn eine Major Page landet.

Du brauchst weniger Schema-Typen als die meisten Plugins emittieren, aber die, die du auslieferst, müssen valide und konsistent sein. Eine kurze Liste deckt neun von zehn Projekten ab.

• Organization — ein einzelner sitewide Graph in deinem Layout mit Logo, sameAs (nur echte Social-Konten), Adresse und contactPoint. Dupliziere dies niemals pro Seite.
• WebSite — einmal im Layout, mit potentialAction für Sitelinks-Suche, falls du eine lokale Suchfunktion hast.
• BreadcrumbList — auf jeder Nicht-Startseite, mit Locale-korrekten URLs (eine französische Seite muss auf /fr/-Vorgänger verweisen, nicht auf /en/).
• Article oder BlogPosting — bei langformatigen Inhalten, mit about- und mentions-Arrays zur Verstärkung des Entity-Graphs.
• Service — auf kommerziellen Seiten, mit serviceType, provider, areaServed, audience und offers.priceSpecification, wenn du eine Preisspanne veröffentlichen kannst.
• Product — im E-Commerce, mit offers.priceCurrency, availability und aggregateRating nur, wenn du echte Bewertungen hast.
• FAQPage — wenn es mindestens zwei echte Fragen auf der Seite gibt. FAQs zu erfinden, um Schema-Markup zu gewinnen, ist der häufigste Grund für manuelle Maßnahmen, die wir bereinigen.
• LocalBusiness oder einen seiner Subtypen — auf Seiten mit physischen Standorten, mit Geokoordinaten und openingHoursSpecification.

Drei Dinge zerstören Schema in der Produktion. Erfindung von Eigenschaften, die schema.org nicht definiert. Erfindung von Werten für sameAs (gefälschte LinkedIn-URLs, aufgegebene Twitter-Handles). Und das Ausliefern widersprüchlicher Organization-Graphs von mehreren Plugins. Wir führen Schema-Validatoren im Build-Linter aus und brechen den Build bei einem dieser drei Muster ab.

Hreflang scheitert im großen Maßstab, weil die Einschränkung bidirektional ist und der Datensatz spärlich. Jede Locale-Variante einer Seite muss sich selbst referenzieren, muss jede andere Variante referenzieren und muss von jeder anderen Variante zurückreferenziert werden. Verpasse eine Richtung auf einer Seite in einer Locale und Google stuft den Cluster stillschweigend herab.

Das Muster, das skaliert

Speichere eine content_group_id (oder Äquivalent) auf jeder übersetzbaren Zeile. Jede Locale-Variante einer Seite teilt sich eine ID. Der hreflang-Emitter, der Sitemap-Emitter und der Canonical-Emitter leiten ihren Cluster alle von dieser ID ab. Berechne hreflang niemals allein aus URL-Pattern-Matching — es fällt bei Edge Cases auseinander (eine spanische Seite, die keine Hindi-Übersetzung hat, zerstört den Cluster, wenn dein Code davon ausgeht, dass „wenn Seite X in Locale A existiert, existiert sie auch in Locale B").

Was hreflang in der Praxis kaputt macht

Drei Muster, die wir wiederholt sehen. Locale-Regex-Reihenfolge — „zh" vor „zh-Hant" in deiner Locale-Detection-Regex zu setzen, was die falsche Locale erfasst und einen fehlerhaften hreflang schreibt. x-default vergessen — jeder Cluster braucht einen x-default-Fallback, normalerweise auf die englische Version zeigend. Cluster-ID-Drift — eine Übersetzung bekommt eine neue ID, statt die Quell-ID zu erben, und teilt einen einzelnen Cluster stillschweigend in zwei unverwandte Cluster auf, von denen keiner einen vollständigen gegenseitigen Satz hat.

Wir fügen immer einen Build-Zeit-hreflang-Linter hinzu, der eine Stichprobe von Seiten crawlt, die hreflang-Cluster durchläuft, auf die sie verweisen, und den Build bricht, wenn ein Cluster unvollständig oder asymmetrisch ist.

Programmatic SEO ist das Generieren von Tausenden Seiten aus einer strukturierten Datenquelle plus einem Template — Verzeichnisse, Vergleichsseiten, Ortsseiten, Glossarseiten. Richtig gemacht kann es den Long-Tail in einem Maßstab treffen, den Single-Author-Content nicht erreichen kann. Falsch gemacht triggert es eine manuelle Action und entfernt die meisten deiner indexierten Seiten über Nacht.

Was einen sauberen programmatic Build von einem Thin-Content-Build unterscheidet

Drei Dinge. Echte Daten pro Seite — jede URL hat mindestens eine Tatsache, Zahl oder Detail, das eindeutig für sie ist; Thin-Programmatic-Seiten teilen sich 95% ihres Inhalts. Ein aussagekräftiges Template — das Template fügt Kontext, Vergleich, Empfehlung oder Aggregation um die eindeutigen Daten hinzu, nicht nur ein suchoptimiertes Wrapper. Und Quality Gating — Seiten mit unzureichenden eindeutigen Daten werden aus der Sitemap gehalten, vom Index blockiert oder in einem Entwurfszustand gehalten, bis die Datenschicht aufgefüllt wird.

Was wir aus der Ausführung im großen Maßstab gelernt haben

Ich habe HostList.io als programmatic-SEO-Plattform mit etwa 28.000 Web-Hosting-Unternehmensseiten auf Next.js plus Supabase gebaut. Die Seiten, die zwei Jahre Google-Updates überstanden haben, waren diejenigen mit mindestens drei eindeutigen Datenpunkten pro URL plus einem Template, das diese Daten verglich, bewertete oder darauf basierend empfahl. Die Seiten, die wir aus dem Index entfernt haben, waren diejenigen, bei denen die eindeutigen Daten nur ein Name und ein Preis waren. Die Kosten, dünne Seiten aus dem Index zu entfernen, waren gering; die Kosten, sie darin zu belassen, waren eine siteweite Ranking-Strafe, als das März-2024-Update für hilfreiche Inhalte kam.

Wir bringen dieses Betriebshandbuch zu Client-Programmatic-Builds — Next.js- oder Astro-Frontend, Supabase- oder Postgres-Daten, eine Ingest-Pipeline, die Seiten auf Eindeutigkeit vor der Veröffentlichung bewertet, eine Sitemap, die in Chunks streamt, weil über 50.000 URLs nicht in eine einzelne sitemap.xml passen, und ein internes Link-Diagramm, das jeden Leaf in einen thematischen Cluster zieht.

Bestehe Core Web Vitals beim 75. Perzentil der Field-Daten, nicht in einem kontrollierten Labor-Lighthouse-Run. Field-Daten von CrUX sind das, was Google nutzt; Lighthouse ist ein Debugging-Tool. Die beiden unterscheiden sich oft um 30% oder mehr auf echten Seiten.

Wo das Budget wirklich hingeht

LCP ist fast immer das Hero-Image und fast immer gelöst durch Neukodierung zu WebP bei 80% Qualität, Skalierung auf die tatsächlichen Anzeigeabmessungen plus 2x Retina, Hinzufügen eines Preload-Tags im Head und Setzen von fetchpriority="high". Ein 1-MB-Hero-Image, das zu einem 30-KB-WebP wird, ist die einzelne höchste Wirkungsänderung in den meisten Projekten. CLS kommt von Bildern und Anzeigen ohne explizite Abmessungen — explizite width- und height-Attribute auf jedem Bild, Anzeigenplätze mit fester Höhe und reservierter Platz für jedes Client-seitige Widget. INP kommt von schwerem JavaScript bei Interaktion — üblicherweise ein Third-Party-Tag-Manager oder eine zu eifrige Analytics-Bibliothek. Die Lösung ist Debouncing, Lazy-Loading oder Ersatz mit einem leichteren Äquivalent.

Wo die meisten Projekte scheitern

Zwei Muster. Erstens ein LCP-Image in einer Carousel-Komponente oder einem JavaScript-gesteuerten Layout — das Bild wird nur nach dem JS-Lauf gerendert, und dein LCP ist das Ladeskelett des Carousels, nicht das Foto. Zweitens Web-Fonts, die ohne font-display: swap und ohne Preload geladen werden — Text ist 200–400 ms lang unsichtbar, während Fonts herunterladen, und dein LCP wird über die 2,5-s-Schwelle verschoben, obwohl das Bild schnell ist. Beides wird durch eine CrUX-Field-Data-Überprüfung erkannt, nicht durch einen einzelnen Lighthouse-Run.

Ein Build-Time-SEO-Linter ist ein Skript, das am Ende deines Builds läuft, eine Schicht der gerenderten HTML-Dateien aus dem Ausgabeverzeichnis sampelt und den Build fehlschlägt, wenn es Muster findet, die SEO in der Produktion verschlechtern würden. Es ist die einzelne höchste Wirkungsgewohnheit, die wir zu Client-Codebasen hinzufügen.

Was unsere Checks überprüfen

• Jede Seite hat genau ein H1.
• Meta-Beschreibung auf jeder indexierbaren URL ist zwischen 120 und 155 Zeichen lang.
• html lang-Attribut entspricht dem Locale-Pfad (eine /fr/-Seite hat lang="fr").
• Hreflang-Cluster sind vollständig und bidirektional auf übersetzbar gemachten Routen.
• JSON-LD auf jeder Seite ist gültig gegen schema.org-Definitionen.
• Keine verbotenen Inhalts-Muster — gefälschte Social-Media-URLs in sameAs, hartcodierter Test-Placeholder-Text, verbotene generische Copywriting-Wörter.
• Canonical URL, die vom Template ausgegeben wird, entspricht der im CMS gespeicherten Canonical.
• WebP-Bilder und explizite Dimensionen-Check auf einer Stichprobe von Templates.

Der Linter wird als letzter Schritt von npm run build ausgeführt. Jede Verletzung lässt den Build fehlschlagen, was den Deploy fehlschlagen lässt. Ohne ihn wird jede Regression — eine Meta-Beschreibung, die über das Limit gewachsen ist, ein SEO-Feld, das jemand vergessen hat zu setzen, ein Schema-Emitter, der brach, als eine Eigenschaft umbenannt wurde — stillschweigend deployed. Mit ihm wird die Regression gefangen, bevor sie den Laptop des Entwicklers verlässt.

Werde zitiert, indem du jede relevante Seite als Stapel zitierreifer Passagen schreibst. Eine zitierreife Passage ist eine Frage-H2, eine direkte ein- bis zweisätzige Antwort unmittelbar danach, unterstützende Nuancen für die nächsten 100–200 Wörter und keine JavaScript-gerenderten Inhalte im Antwortblock. AI-Extraktoren heben diesen Anfangssatz heraus und zitieren die Seite.

Was über die Passage-Struktur hinaus hilft

• Entity-Autorität — Wikipedia-Präsenz, konsistentes Organisation-Schema, echte sameAs-Konten, Markenerwähnungen im offenen Web.
• llms.txt im Site-Root — eine kuratierte Karte der Site für AI-Tools, getrennt von robots.txt und sitemap.xml, die traditionelle Crawler bedienen.
• Schema mit about und mentions auf längeren Inhalten — deklariert den Entity-Graph, in dem die Seite sitzt.
• AI-Crawler robots.txt Allow-List — erlaube explizit GPTBot, PerplexityBot, ClaudeBot, OAI-SearchBot, Google-Extended, Applebot-Extended, CCBot und Anthropic-AI. Auch nur einen dieser zu blockieren ist ein selbstverschuldeter Zitierausfall.
• Speakable-Schema-Eigenschaft auf antwortreichen Abschnitten langer Seiten — ein Hinweis an Sprach- und AI-Extraktoren, dass dies die zitierbare Passage ist.

Zitate zu verfolgen ist der Teil, den die meisten Teams überspringen. Otterly, Profound und AthenaHQ verfolgen AI-Overview- und Perplexity-Zitieranteile nach Domain. Wir fügen wöchentliches Zitat-Tracking neben jedem Engagement hinzu und melden es zusammen mit organischem Traffic. Wenn du Zitate nicht misst, kannst du nicht sehen, ob deine GEO-Arbeit etwas bewirkt.

KI-Crawler können deine Website nur lesen, wenn deine robots.txt ihren User-Agent explizit erlaubt und deine Hosting-Schicht sie nicht am Netzwerk-Edge blockiert. Beide Prüfungen müssen bestanden werden. Standard-Cloudflare-Einstellungen, Standard-Vercel-WAF-Regeln und Standard-WordPress-Security-Plugins blockieren KI-Bots routinemäßig ohne Warnung.

Die robots.txt-Allowlist, die wir ausliefern

GPTBot und ChatGPT-User und OAI-SearchBot für ChatGPT und OpenAI-Suchprodukte. PerplexityBot und Perplexity-User. ClaudeBot und Claude-Web und anthropic-ai. Google-Extended für Bard und AI Overviews. Applebot-Extended. CCBot für Common Crawl, das viele Open-Source-Modelle speist. Cohere-AI. Meta-ExternalAgent. Bytespider — TikToks Crawler — normalerweise blockiert, weil er aggressiv ist und die meisten Projekte nicht wollen, dass TikTok ihre Inhalte übernimmt.

Was du zusätzlich tun musst

Robots.txt ist notwendig, aber nicht ausreichend. Drei weitere Prüfungen. Cloudflare Bot Fight Mode und Bot Management — deaktiviere die, die KI-Agenten blockieren, oder whitelist sie nach IP und User-Agent. Vercel WAF und Edge Middleware — stelle sicher, dass sie KI-User-Agents nicht mit generischen Regex abgleichen. WordPress-Security-Plugins wie Wordfence — sie enthalten oft Regeln, die standardmäßig GPTBot und PerplexityBot blockieren; whitelist sie explizit. Teste jeden User-Agent mit curl gegen drei repräsentative URLs und bestätige eine 200-Antwort.

Wir bauen technische SEO-Fundamente auf, die dem UK Government Digital Service Standard und dem GOV.UK Design System entsprechen. Der GDS Service Standard ist die am strengsten dokumentierte Sammlung von Qualitätsprinzipien für digitale Dienste im öffentlichen Bereich: Progressive Enhancement, Barrierefreiheit nach WCAG 2.2 AA, Performance, semantisches HTML und graziöse Degradation bei JavaScript-Ausfällen. Wir folgen ihm bei jedem technischen SEO-Engagement bei Seahawk.Government Digital Service Standard and the GOV.UK Design System. The GDS Service Standard is the most rigorously documented set of digital-service quality principles in the public domain: progressive enhancement, accessibility to WCAG 2.2 AA, performance, semantic HTML, and graceful degradation when JavaScript fails. We follow it on every Seahawk technical SEO engagement.

Warum das speziell für SEO wichtig ist: GDS-konforme Websites bestehen Core Web Vitals konsistent, ranken gut in klassischer organischer Suche und sind einzigartig gut geeignet für AI Overview-Zitate, weil die strukturelle Klarheit, die GDS fordert, dieselbe strukturelle Klarheit ist, die AI-Oberflächenextraktionen nutzen. Der Standard entstand vor der AI-Such-Ära, passt aber perfekt dazu.

Für UK-Unternehmensclients, öffentlichen Sektor und Clients aus regulierten Branchen ist GDS-Konformität ein echtes Beschaffungssignal. Für alle anderen ist es ein Qualitätsmerkmal, das die Arbeit von Agenturen mit niedrigerem Standard unterscheidet.

Drei bis zehn Wochen, drei Phasen, Festpreis. Phase eins ist Audit — vollständiger Crawl, GSC- und Ahrefs-Review, JSON-LD-Validierung, hreflang-Cluster-Check, Core Web Vitals Felddata-Abzug, AI-Zitat-Baseline. Phase zwei ist Behebung — wir liefern die Fixes, dein Team oder unseres. Phase drei ist die Linter- und Monitoring-Schicht, die Regressionsfehler verhindert.

Die Liefergegenstände der Audit-Phase

• Vollständiger Screaming Frog-Crawl als CSV plus ein schriftliches Briefing zu den wichtigen Problemen, nach Impact geordnet.
• Search Console-Export — Coverage-Report, Queries, seitenbezogene Performance — mit Anmerkungen zu Anomalien.
• Schema-Validator-Durchgang über eine Stichprobe von Templates und eine schriftliche Notiz zu jedem Typ, der kaputt oder fehlend ist.
• Hreflang-Cluster-Integritätsbericht zu den übersetzbaren Routes.
• Core Web Vitals Felddata-Abzug aus CrUX mit einem Diagramm der letzten 25 Wochen pro Metrik.
• AI Overview und Perplexity Citation Baseline — aktueller Marktanteil, Gap-Analyse gegen drei benannte Konkurrenten.

Die Remediation-Phase

Fixed-Scope-Arbeiten. Jedes Ticket hat einen klaren Vorher- und Nachher-Zustand. Wir versenden sie nach Priorität und du kannst die Zusammenarbeit bei jedem Meilenstein beenden, wenn das Budget aufgebraucht ist. Der erste Batch, den wir versenden, sind immer die Items, die den Build Linter nicht bestehen — sie haben den kürzesten Weg zum Wert, weil sie ohne den Linter immer wieder Regrессionen verursachen, und sobald der Linter aktiv ist, bleibt jede Behebung bestehen.

Die Monitoring-Phase

Wöchentliche automatisierte Linting auf Staging und Production, monatlicher Core Web Vitals Report, monatliches AI Citation Tracking und ein einsatzfähiger Slack-Kanal, in dem ich auf alles reagiere, das Google oder dein Team flaggen. Wir übergeben die Dashboards beim Abschluss, sodass du die Sichtbarkeit behältst, ob du verlängerst oder nicht.