Technisches SEO, das KI-Überprüfungen, Headless-Umstellungen und Ihr nächstes Algorithmus-Update übersteht.

Technisches SEO ist der Arbeitsbereich, der darüber entscheidet, ob Suchmaschinen und KI-Assistenten Ihre Seiten crawlen, rendern und als vertrauenswürdig einstufen können – noch bevor Inhalte oder Backlinks überhaupt eine Rolle spielen. Dazu gehören HTTP-Verhalten, HTML-Semantik, strukturierte Daten, hreflang, Kanonisierung, Core Web Vitals und JavaScript-Rendering. Wenn Sie hier Fehler machen, ist der Rest Ihrer Investition reine Verschwendung.

Im Jahr 2026 hat sich die Definition erweitert. Zwei Veränderungen haben dazu beigetragen. Erstens stehen nun KI-Übersichten und die ChatGPT-gestützte Suche zwischen den meisten Nutzern und den zugrunde liegenden Seiten, was bedeutet, dass die Zitierfähigkeit genauso wichtig ist wie das Ranking. Zweitens handelt es sich bei der modalen Website nicht mehr um eine WordPress-Installation, sondern um eine Art Headless-Frontend, das Inhalte aus Sanity, Strapi, Payload, Storyblok, Contentful oder einem Headless-WordPress-Backend bezieht. Jede dieser Plattformen bringt ihre eigenen technischen SEO-Fehlerquellen mit sich, die im alten Leitfaden nicht berücksichtigt sind.

Meine Arbeitsdefinition für Kunden im Jahr 2026: Technisches SEO umfasst alles, was ein Lighthouse-Test, ein Crawl-Bericht der Search Console, eine Zitierprüfung mit AI Overview und eine Meldung des Schema-Validators ergeben – und zwar für jede Ländereinstellung, jede Vorlage und jeden Render-Pfad. Wenn eines dieser vier Signale bei einer repräsentativen URL fehlschlägt, beginnt dort die Zusammenarbeit.

Bei einer Headless- oder Jamstack-Website ist das Frontend-Framework für die Darstellung zuständig, während das CMS die Inhalte verwaltet – und SEO kann dabei durch die Lücke zwischen beiden fallen. Das klassische WordPress-Yoast-Modell ging von einem Server, einem Renderer und einer Regel-Engine aus. Wenn Sie Inhalte aus WordPress in Next.js oder Astro übertragen, wird nichts davon automatisch übernommen.

Reine moderne Stapel

Ein Next.js- + Sanity-Build, ein Astro- + Storyblok-Build, ein Nuxt- + Strapi-Build und ein Next.js- + Payload-Build – alle verzichten komplett auf WordPress. Die technischen SEO-Maßnahmen konzentrieren sich nun darauf, sicherzustellen, dass Ihr CMS-Schema die vom Frontend benötigten SEO-Felder abbildet (Canonical-Überschreibung, Redirect-Map, hreflang-Gruppe, Schema-Extension-JSON) und dass bei Inhaltsänderungen eine bedarfsgesteuerte Neuvalidierung ausgelöst wird. ISR-Cache-Poisoning ist der stille Killer: Eine Seite wird nach der Veröffentlichung stundenlang in veralteter Form ausgeliefert, weil „revalidatePath“ nie eingerichtet wurde.

Was geht eigentlich zuerst kaputt?

Bei den rund 200 „Headless“-Audits, die wir durchgeführt haben, war das häufigste Problem, das zu Produktionsausfällen führte, ein Kanonischer-URL-Konflikt: Das Frontend gibt eine kanonische URL aus, während die CMS-Metadaten oder die Sitemap eine andere ausgeben. Google wählt eine davon aus – fast immer nicht die, die man eigentlich wollte – und die falsche URL landet schließlich im Index. Wir erkennen dies mithilfe eines Linters, der bereits während der Build-Phase bei einer Stichprobe von Seiten die aus der Vorlage ausgegebene kanonische URL mit der im CMS gespeicherten kanonischen URL vergleicht und den Build bei Nichtübereinstimmung abbricht.

WordPress bietet Ihnen die größte Auswahl an Plugins – und die meisten Möglichkeiten, sich selbst ins Bein zu schießen. Bei der technischen SEO einer klassischen WordPress-Website geht es vor allem um das Weglassen: das Entfernen doppelter Canonical-Tags, das Beenden von Schema-Konflikten zwischen Yoast und RankMath sowie einem dritten Plugin, an dessen Installation sich niemand mehr erinnert, das Zügeln von Page-Buildern, die 2 MB CSS mitbringen, und das Aufräumen von Weiterleitungsketten, die sich über acht Jahre hinweg angesammelt haben.

Die von uns für 2026 empfohlene Standardkonfiguration: ein einziges SEO-Plugin (RankMath oder Yoast, niemals beide), ein Managed-Hosting-Anbieter mit ordnungsgemäßem Edge-Caching (Cloudways, Kinsta, WP Engine), Bricks Builder für Neuentwicklungen, bei denen es auf Leistung ankommt, oder natives Gutenberg mit Kadence oder Blocksy, ein Redirect-Manager, der in ein portables Format exportiert, sowie Perfmatters oder FlyingPress zur Bereinigung von Assets. Bei der Audit-Arbeit geht es darum, herauszufinden, welche dieser Entscheidungen auf Ihrer Website anders getroffen wurden, und die daraus resultierenden Konsequenzen zu beheben.

Im Headless-Bereich verlagert sich der Schwerpunkt von der Reduktion hin zur Konstruktion. Da es kein Yoast gibt, muss die Meta-Daten-Erstellung selbst implementiert werden. Da es kein Plugin-Schema gibt, müssen JSON-LD-Vorlagen erstellt werden. Es gibt keine integrierte Sitemap, daher muss diese generiert und gestreamt werden. Der Codeumfang, den wir einem Headless-Projekt für SEO hinzufügen, ist in der Regel drei- bis fünfmal so groß wie das, was eine WordPress-Seite bereits kostenlos bietet, aber dieser Code gehört uns, unterliegt der Versionskontrolle, ist testbar und fällt beim nächsten Plugin-Update nicht aus.

GEO und AEO sind die Bezeichnungen für zwei verschiedene Arten, wie KI-Funktionen Suchverkehr abziehen. AEO (Answer Engine Optimisation) ist der ältere Begriff; er umfasst Google-Funktionen wie „Featured Snippets“, „People Also Ask“ und „Knowledge Panels“, die einen Auszug aus Ihrer Seite entnehmen und ihn als Antwort anzeigen. GEO (Generative Engine Optimisation) ist der neuere Begriff und bezieht sich auf die Optimierung für KI-Übersichten, die ChatGPT-Suche, Perplexity und Bing Copilot, bei denen der Assistent einen Absatz generiert und Ihre Seite als Quelle angibt.

Was das strukturell bedeutet

Beide Plattformen wollen dasselbe: einen zitierfähigen Textabschnitt. Die strukturellen Regeln, die bei allen gleichermaßen gelten, sind dieselben. Verwenden Sie eine Frage als H2-Überschrift, keine Themenbezeichnung. Platzieren Sie die Antwort in den ersten ein oder zwei Sätzen nach der Überschrift. Die Antwort sollte nicht länger als 250 Wörter sein. Stellen Sie sicher, dass die Antwort serverseitig gerendert wird und nicht in einer JavaScript-Komponente, die erst nach dem Laden der Seite geladen wird. KI-Crawler und Google-Extraktoren führen JavaScript meist nicht aus. Wenn Ihre Antwort JS benötigt, um angezeigt zu werden, sind Sie unsichtbar.

Inwiefern sich GEO von AEO unterscheidet

Drei Dinge sind speziell für GEO besonders wichtig: Entitätsautorität, Google und die LLMs erstellen ein Netzwerk, das festlegt, wer über was sprechen darf, und nicht verknüpfte Markenerwähnungen speisen dieses Netzwerk. Schema-Daten mit „about“- und „mentions“-Arrays sorgen dafür, dass Ihre Seite als Teil eines Entitätsnetzwerks und nicht als reine Textwand analysiert werden kann. Und „llms.txt“, eine sich etablierende Standarddatei unter /llms.txt, die KI-Tools eine kuratierte Übersicht über Ihre Website liefert – genauso wie „robots.txt“ und „sitemap.xml“ Such-Crawlern helfen. Wir setzen „llms.txt“ auf jeder von uns erstellten Website ein und aktualisieren sie, sobald eine wichtige Seite online geht.

Sie benötigen weniger Schematypen, als die meisten Plugins bereitstellen, aber die von Ihnen bereitgestellten müssen gültig und konsistent sein. Eine kurze Liste deckt neun von zehn Projekten ab.

• Organisation: Ein einziger, für die gesamte Website geltender Graph in Ihrem Layout, mit Logo, „sameAs“ (nur echte Social-Media-Konten), Adresse und „contactPoint“. Duplizieren Sie diesen niemals auf jeder einzelnen Seite.
• Website, einmal im Layout, mit der Funktion „potentialAction“ für die Suche nach Sitelinks, sofern Sie über eine interne Suche verfügen.
• Breadcrumb-Liste auf jeder Seite außer der Startseite mit landessprachlich korrekten URLs (eine französische Seite muss auf Vorläufer unter /fr/ verweisen, nicht unter /en/).
• Artikel oder Blogbeitrag zu Langform-Inhalten mit „About“- und „Mentions“-Arrays zur Stärkung des Entitätsgraphen.
• Dienstleistung auf kommerziellen Seiten mit den Feldern „serviceType“, „provider“, „areaServed“, „audience“ und „offers.priceSpecification“, wenn Sie eine Preisspanne angeben können.
• Produkt im E-Commerce mit „offers.priceCurrency“, Verfügbarkeit und „aggregateRating“ (nur, wenn echte Bewertungen vorliegen).
• FAQ-Seite, sofern die Seite mindestens zwei echte Fragen enthält. Das Fälschen von FAQs, um Schema-Markup zu erhalten, ist der häufigste Auslöser für manuelle Maßnahmen, den wir beseitigen.
• „LocalBusiness“ oder einer seiner Untertypen auf Seiten mit physischen Standorten, mit GEO-Koordinaten und „openingHoursSpecification“.

Drei Dinge führen dazu, dass Schema in der Produktion fehlschlägt: Das Erfinden von Eigenschaften, die schema.org nicht definiert; das Erfinden von Werten für „sameAs“ (gefälschte LinkedIn-URLs, nicht mehr verwendete Twitter-Handles); und das Übermitteln widersprüchlicher Organisationsgraphen aus mehreren Plugins. Wir führen Schema-Validatoren im Build-Linter aus und brechen den Build ab, sobald eines dieser drei Muster auftritt.

Hreflang versagt im großen Maßstab, weil die Einschränkung bidirektional ist und der Datensatz lückenhaft ist. Jede Sprachvariante einer Seite muss auf sich selbst verweisen, auf jede andere Variante verweisen und von jeder anderen Variante zurückverwiesen werden. Fehlt auf einer Seite in einer Sprachvariante eine Verweisschlange in eine Richtung, stuft Google den Cluster stillschweigend herab.

Das skalierbare Muster

Speichern Sie eine „content_group_id“ (oder eine entsprechende Kennung) in jeder übersetzbaren Zeile. Jede Sprachvariante einer Seite hat eine gemeinsame ID. Der hreflang-Emitter, der Sitemap-Emitter und der canonical-Emitter leiten ihren Cluster jeweils von dieser ID ab. Berechnen Sie hreflang niemals allein anhand eines URL-Musterabgleichs, da dies in Randfällen zu Fehlern führt (eine spanische Seite ohne Hindi-Übersetzung zerstört den Cluster, wenn Ihr Code davon ausgeht: „Wenn Seite X in Sprachvariante A existiert, existiert sie auch in Sprachvariante B“).

Was macht „hreflang“ in der Praxis zunichte?

Drei Muster, die wir immer wieder beobachten: Die Reihenfolge in den Regex-Ausdrücken für die Ländereinstellung – wenn „zh“ in Ihrem Regex-Ausdruck zur Ländereinstellungserkennung vor „zh-Hant“ steht, wird die falsche Ländereinstellung erfasst und ein fehlerhafter „hreflang“-Attributwert geschrieben. Das Vergessen von „x-default“: Jeder Cluster benötigt einen „x-default“-Fallback, der in der Regel auf die englische Version verweist. Abweichung bei der Cluster-ID: Eine Übersetzung erhält eine neue ID, anstatt die Quell-ID zu übernehmen, wodurch ein einzelner Cluster stillschweigend in zwei voneinander unabhängige Cluster aufgeteilt wird, von denen keiner über einen vollständigen reziproken Satz verfügt.

Wir fügen stets einen „hreflang“-Linter für die Build-Phase hinzu, der eine Stichprobe von Seiten durchsucht, die darin referenzierten „hreflang“-Cluster durchläuft und den Build abbricht, wenn ein Cluster unvollständig oder asymmetrisch ist.

Programmatisches SEO erzeugt Tausende von Seiten aus einer strukturierten Datenquelle in Verbindung mit einer Vorlage, Verzeichnissen, Vergleichsseiten, Standortseiten und Glossarseiten. Richtig umgesetzt, kann es den Long-Tail in einem Umfang abdecken, den Inhalte eines einzelnen Autors nicht erreichen können. Falsch umgesetzt, löst es eine manuelle Maßnahme aus und führt dazu, dass die meisten Ihrer indexierten Seiten über Nacht entfernt werden.

Was unterscheidet einen sauberen programmatischen Aufbau von einem mit dünnem Inhalt?

Drei Dinge. Echte Daten pro Seite: Jede URL enthält mindestens eine Tatsache, eine Zahl oder ein Detail, das für sie einzigartig ist; programmatisch erstellte Seiten mit geringem Inhalt teilen sich 95 % ihres Inhalts. Eine aussagekräftige Vorlage: Die Vorlage fügt den einzigartigen Daten Kontext, Vergleiche, Empfehlungen oder Zusammenfassungen hinzu und ist nicht nur eine suchoptimierte Hülle. Und Qualitätskontrolle: Seiten mit unzureichenden einzigartigen Daten werden aus der Sitemap ausgeschlossen, von der Indizierung blockiert oder im Entwurfsstatus gehalten, bis die Datenebene vervollständigt ist.

Was wir aus der Umsetzung dieses Vorhabens in großem Maßstab gelernt haben

Ich habe HostList.io als programmatische SEO-Plattform mit Seiten für mehr als 30.000 Webhosting-Anbieter auf Basis von Next.js und Supabase entwickelt. Die Seiten, die zwei Jahre lang alle Google-Updates überstanden haben, waren diejenigen mit mindestens drei einzigartigen Datenpunkten pro URL sowie einer Vorlage, die diese Daten verglich, bewertete oder Empfehlungen aussprach. Die Seiten, die wir aus dem Index entfernt haben, waren diejenigen, bei denen die einzigartigen Daten lediglich aus einem Namen und einem Preis bestanden. Der Aufwand, inhaltsarme Seiten aus dem Index zu entfernen, war gering; der Preis, sie darin zu belassen, war eine siteweite Ranking-Abstrafung, als im März 2024 das „Helpful Content“-Update in Kraft trat.

Wir wenden dieses Betriebshandbuch auf die programmatische Entwicklung für Kunden an: Next.js- oder Astro-Frontend, Supabase- oder Postgres-Daten, eine Erfassungspipeline, die Seiten vor der Veröffentlichung auf Einzigartigkeit bewertet, eine Sitemap, die in Teilen gestreamt wird, da über 50.000 URLs nicht in eine einzige sitemap.xml passen, und ein internes Link-Netzwerk, das jedes Blatt in einen thematischen Cluster einordnet.

Die Core Web Vitals sollten im 75. Perzentil der Felddaten erfüllt werden, nicht in einem kontrollierten Lighthouse-Lauf unter Laborbedingungen. Google verwendet Felddaten aus CrUX; Lighthouse ist ein Debugging-Tool. Bei realen Websites weichen die beiden Ergebnisse oft um 30 % oder mehr voneinander ab.

Wohin das Budget tatsächlich fließt

LCP wird fast immer durch das Hero-Bild verursacht und lässt sich fast immer beheben, indem man es mit 80 % Qualität in das WebP-Format umcodiert, die Größe an die tatsächlichen Bildschirmabmessungen plus 2x Retina anpasst, ein Preload-Tag im Head-Bereich hinzufügt und „fetchpriority="high"“ festlegt. Ein 1 MB großes Hero-Bild, das zu einer 30 KB großen WebP-Datei wird, ist bei den meisten Projekten die Änderung mit der größten Wirkung. CLS entsteht durch Bilder und Anzeigen ohne explizite Abmessungen, fehlende „width“- und „height“-Attribute bei jedem Bild, Anzeigenplätze mit fester Höhe sowie reservierten Platz für clientseitige Widgets. INP entsteht durch aufwendiges JavaScript bei Interaktionen, meist durch einen Tag-Manager eines Drittanbieters oder eine übermäßig eifrige Analytics-Bibliothek. Die Lösung besteht darin, Debouncing anzuwenden, Lazy-Loading zu nutzen oder die Komponente durch ein leichteres Äquivalent zu ersetzen.

Wo die meisten Projekte scheitern

Zwei Muster. Erstens: Ein LCP-Bild innerhalb einer Karussell-Komponente oder eines JavaScript-gesteuerten Layouts – das Bild wird erst gerendert, nachdem das JavaScript ausgeführt wurde, und Ihr LCP ist das Ladegerüst des Karussells, nicht das Foto. Zweitens: Webfonts, die ohne „font-display: swap“ und ohne Vorladen geladen werden. Der Text ist 200–400 ms lang unsichtbar, während die Schriftarten heruntergeladen werden, und Ihr LCP überschreitet die 2,5-Sekunden-Schwelle, obwohl das Bild schnell geladen wird. Beide Fälle werden bei einer Überprüfung der CrUX-Felddaten erfasst, nicht bei einem einzelnen Lighthouse-Lauf.

Ein SEO-Linter für die Build-Phase ist ein Skript, das am Ende Ihres Builds ausgeführt wird, eine Stichprobe der gerenderten HTML-Dateien aus dem Ausgabeverzeichnis überprüft und den Build abbricht, wenn es Muster findet, die die SEO in der Produktionsumgebung beeinträchtigen würden. Dies ist die Maßnahme mit der größten Wirkung, die wir in die Codebasen unserer Kunden integrieren.

Was unsere Prüfung umfasst

• Jede Seite enthält genau eine H1-Überschrift.
• Die Meta-Beschreibung jeder indexierbaren URL ist zwischen 120 und 155 Zeichen lang.
• Das HTML-Attribut „lang“ stimmt mit dem Sprachpfad überein (eine Seite unter /fr/ hat lang="fr").
• Hreflang-Cluster sind auf übersetzbaren Routen vollständig und bidirektional.
• JSON-LD auf jeder Seite entspricht den Definitionen von schema.org.
• Keine verbotenen Inhaltsmuster, keine gefälschten Social-Media-URLs in „sameAs“, kein fest programmierter Platzhaltertext für Testzwecke, keine verbotenen allgemeinen Werbetexte.
• Die von der Vorlage generierte kanonische URL stimmt mit der im CMS gespeicherten kanonischen URL überein.
• Überprüfung von WebP-Bildern und expliziten Abmessungen anhand einer Stichprobe von Vorlagen.

Der Linter wird als letzter Schritt von „npm run build“ ausgeführt. Jeder Verstoß führt zum Fehlschlagen des Builds, wodurch auch die Bereitstellung fehlschlägt. Ohne ihn würden alle Regressionen – sei es eine Meta-Beschreibung, die das zulässige Limit überschreitet, ein SEO-Feld, das jemand vergessen hat zu setzen, oder ein Schema-Emitter, der durch die Umbenennung einer Eigenschaft nicht mehr funktioniert – unbemerkt veröffentlicht werden. Mit ihm wird die Regression erkannt, bevor sie den Laptop des Entwicklers verlässt.

Sorgen Sie dafür, dass Ihre Seite zitiert wird, indem Sie jede relevante Seite als eine Sammlung zitierfähiger Passagen verfassen. Eine zitierfähige Passage besteht aus einer H2-Überschrift in Form einer Frage, einer direkten Antwort von ein bis zwei Sätzen unmittelbar danach, ergänzenden Erläuterungen in den folgenden 100 bis 200 Wörtern sowie keinerlei durch JavaScript gerenderten Inhalten im Antwortblock. KI-Extraktoren greifen diesen ersten Satz auf und zitieren die Seite.

Was über die Textstruktur hinaus hilft

• Entitätsautorität, Wikipedia-Präsenz, einheitliches Organisationsschema, echte „sameAs“-Konten, Markenerwähnungen im gesamten offenen Web.
• Die Datei „llms.txt“ im Stammverzeichnis der Website ist eine kuratierte Sitemap für KI-Tools und unterscheidet sich von den Dateien „robots.txt“ und „sitemap.xml“, die für herkömmliche Crawler bestimmt sind.
• Das Schema mit „About“- und „Mentions“-Angaben zu Langform-Inhalten definiert den Entitätsgraphen, in dem die Seite eingebettet ist.
• AI-Crawler-Robots.txt-Whitelist: GPTBot, PerplexityBot, ClaudeBot, OAI-SearchBot, Google-Extended, Applebot-Extended, CCBot und Anthropic-AI ausdrücklich zulassen. Das Blockieren auch nur eines dieser Bots führt zu einem selbstverschuldeten Ausfall der Zitationsdaten.
• Die Eigenschaft „Speakable“ in den antwortreichen Abschnitten von Langform-Seiten dient als Hinweis für Sprach- und KI-Extraktoren, dass es sich hierbei um die zitierfähige Passage handelt.

Das Nachverfolgen von Zitaten ist der Teil, den die meisten Teams überspringen. Otterly, Profound und AthenaHQ erfassen den Anteil der Zitate aus „AI Overview“ und „Perplexity“ nach Domain. Wir ergänzen jede Interaktion um eine wöchentliche Zitaterfassung und berichten darüber zusammen mit dem organischen Traffic. Wenn Sie Zitate nicht messen, können Sie nicht feststellen, ob Ihre GEO-Maßnahmen überhaupt etwas bewirken.

KI-Crawler können Ihre Website nur dann auslesen, wenn Ihre robots.txt-Datei ihren User-Agent ausdrücklich zulässt und Ihre Hosting-Ebene sie nicht am Netzwerkrand blockiert. Beide Prüfungen müssen erfolgreich sein. Die Standardeinstellungen von Cloudflare, die Standard-WAF-Regeln von Vercel und die Standard-Sicherheits-Plugins von WordPress blockieren KI-Bots routinemäßig ohne Vorwarnung.

Die von uns bereitgestellte „allow“-Liste für die robots.txt-Datei

GPTBot und ChatGPT-User sowie OAI-SearchBot für ChatGPT und die Suchprodukte von OpenAI. PerplexityBot und Perplexity-User. ClaudeBot, Claude-Web und anthropic-ai. Google-Extended für Bard und KI-Übersichten. Applebot-Extended. CCBot für Common Crawl, das viele Open-Source-Modelle mit Daten versorgt. Cohere-AI. Meta-ExternalAgent. Bytespider, der Crawler von TikTok, der in der Regel blockiert wird, da er aggressiv vorgeht und die meisten Projekte nicht möchten, dass TikTok ihre Inhalte abgreift.

Was Sie außerdem tun müssen

Die Datei „robots.txt“ ist notwendig, reicht aber nicht aus. Drei weitere Überprüfungen: Der „Bot Fight“-Modus und die Bot-Verwaltung von Cloudflare – deaktivieren Sie die Funktionen, die KI-Agenten blockieren, oder setzen Sie diese anhand ihrer IP-Adresse und ihres User-Agents auf die Whitelist. Vercel WAF und Edge Middleware: Stellen Sie sicher, dass diese KI-User-Agents nicht anhand eines generischen regulären Ausdrucks erkannt werden. WordPress-Sicherheits-Plugins wie Wordfence enthalten oft Regeln, die GPTBot und PerplexityBot standardmäßig blockieren; setzen Sie diese ausdrücklich auf die Whitelist. Testen Sie dies, indem Sie jeden User-Agent mit einem Curl-Befehl an drei repräsentative URLs senden und eine 200-Antwort überprüfen.

Wir schaffen technische SEO-Grundlagen, die sich nach dem britischen Government Digital Service Standard und dem GOV.UK Design System richten. Der GDS Service Standard ist die am gründlichsten dokumentierte Sammlung von Qualitätsprinzipien für digitale Dienste im öffentlichen Bereich: Progressive Enhancement, Barrierefreiheit nach WCAG 2.2 AA, Performance, semantisches HTML und anmutiges Degradieren bei JavaScript-Fehlern. Ich befolge ihn bei jedem technischen SEO-Engagement.

Warum dies speziell für SEO von Bedeutung ist: GDS-konforme Websites erfüllen die Core Web Vitals durchweg, erzielen gute Platzierungen in den klassischen organischen Suchergebnissen und eignen sich besonders gut für Zitate im Rahmen des „AI Overview“, da die von GDS geforderte strukturelle Klarheit genau der strukturellen Klarheit entspricht, aus der KI-Overviews ihre Informationen extrahieren. Der Standard stammt zwar aus der Zeit vor dem Zeitalter der KI-Suche, passt aber perfekt dazu.

Für Kunden aus der britischen Unternehmenswelt, dem öffentlichen Sektor und regulierten Branchen ist die GDS-Konformität ein echtes Beschaffungssignal. Für alle anderen ist sie ein Qualitätsmerkmal, das die Arbeit von Agenturen abhebt, die sich mit niedrigeren Standards begnügen.

Drei bis zehn Wochen, drei Phasen, Festpreis. Phase eins umfasst ein Audit, einen vollständigen Crawl, eine Überprüfung mit GSC und Ahrefs, eine JSON-LD-Validierung, eine Überprüfung der hreflang-Cluster, das Erfassen von Felddaten zu den Core Web Vitals sowie eine KI-basierte Zitations-Baseline. Phase zwei ist die Behebung von Mängeln: Wir liefern die Korrekturen – entweder durch Ihr Team oder durch unser Team. Phase drei umfasst den Linter und die Überwachungsebene, die Rückschritte verhindert.

Ergebnisse der Prüfungsphase

• Vollständiger Screaming-Frog-Crawl im CSV-Format sowie eine schriftliche Zusammenfassung der wichtigsten Probleme, geordnet nach ihrer Auswirkung.
• Search Console-Export, Abdeckungsbericht, Suchanfragen, Leistung auf Seitenebene, mit Anmerkungen zu Auffälligkeiten.
• Der Schema-Validator durchläuft eine Stichprobe von Vorlagen und erstellt zu jedem fehlerhaften oder fehlenden Typ eine schriftliche Notiz.
• Bericht zur Integrität der hreflang-Cluster für die übersetzbaren Routen.
• Core Web Vitals: Felddaten aus CrUX mit einem Diagramm der letzten 25 Wochen pro Kennzahl.
• KI-Überblick und Perplexity-Zitations-Baseline, aktueller Marktanteil, Lückenanalyse im Vergleich zu drei namentlich genannten Wettbewerbern.

Die Sanierungsphase

Arbeiten mit festgelegtem Umfang. Jedes Ticket weist einen klaren Ausgangszustand und einen Endzustand auf. Wir liefern die Tickets in der Reihenfolge ihrer Priorität aus, und Sie können das Projekt an jedem Meilenstein beenden, falls das Budget erschöpft ist. Die erste Charge, die wir ausliefern, besteht immer aus den Elementen, die den Build-Linter nicht bestehen. Diese bieten den kürzesten Weg zum Nutzen, da sie ohne den Linter immer wieder zu Fehlern führen würden; sobald der Linter jedoch integriert ist, bleiben alle Korrekturen dauerhaft bestehen.

Die Überwachungsphase

Wöchentliche automatisierte Linting-Prüfung auf Staging- und Produktionsumgebungen, monatlicher Core Web Vitals-Bericht, monatliche Nachverfolgung von KI-Zitaten sowie ein aktiv gehaltener Slack-Kanal, in dem ich auf alle Punkte reagiere, die Google oder Ihr Team melden. Bei Vertragsende übergeben wir Ihnen die Dashboards, damit Sie weiterhin den Überblick behalten, unabhängig davon, ob Sie den Vertrag verlängern oder nicht.