Am 21. Februar 2026 war pragma-code.de ein leeres Astro-Projekt. Heute liefert die Google Search Console für die Domain 45.443 Impressionen in 28 Tagen. Dieser Artikel ist kein Erfolgsmärchen, sondern ein Werkstattbericht: jede Maßnahme mit Datum, jede Zahl aus der Search-Console-API – und die Pannen, die uns dabei Deploys, Rankings und ein paar Nerven gekostet haben.
Dieser Artikel ist ein vertiefender Fachbeitrag aus unserem Content-Cluster. Entdecken Sie die vollständige Übersicht auf unserer Hauptseite:Technisches SEO-Audit →
- Das Ergebnis: 101.478 Impressionen und 580 Klicks zwischen dem 1. März und dem 11. August 2026 – aus einem Projekt, das am 21. Februar 2026 als leeres Astro-Repository begann. Alle Zahlen stammen aus der Search-Console-API mit
dataState: final. - Der Hebel war nicht Content allein: Die Kurve knickt nach oben, als Performance-Umbau, englische Slugs mit korrektem hreflang und aktive Indexierung zusammenfielen – nicht, als der hundertste Artikel erschien.
- Der ehrliche Teil: Ein roter Deploy durch einen erfundenen Icon-Namen, literale Sternchen auf 16 Seiten, 47 interne 404-Links und ein lokaler rsync, der eine frisch deployte Seite auf 404 zurücksetzte. Jede dieser Pannen hat eine Regel hinterlassen.
Es gibt viele Artikel darüber, wie man Sichtbarkeit aufbaut. Die wenigsten legen dabei die eigenen Zahlen offen, und noch weniger nennen die Maßnahmen mit Datum. Dieser hier tut beides – aus dem einfachen Grund, dass wir die Domain, um die es geht, selbst betreiben: pragma-code.de.
Der Ausgangspunkt ist unspektakulär. Am 21. Februar 2026 steht im Git-Log der erste Commit: „Initial commit from Astro“. Ein leeres Gerüst. In der Google Search Console meldet die Domain in den ersten 28 Tagen nach dem Livegang genau 1.531 Impressionen und 9 Klicks, verteilt auf 57 Suchanfragen. Das ist, in der Praxis, null. Niemand findet diese Website.
Fünfeinhalb Monate später, in den 28 Tagen bis zum 11. August 2026, meldet dieselbe Property 45.443 Impressionen, 285 Klicks und 2.476 unterschiedliche Suchanfragen. 586 einzelne URLs erscheinen mindestens einmal in den Suchergebnissen. Das ist knapp das Dreißigfache an Impressionen und das Dreiundvierzigfache an Suchanfragen, für die die Domain überhaupt in Erscheinung tritt.
Abbildung: Täglicher Verlauf von Klicks und Impressionen laut Google Search Console (API, dataState: final). Die gestrichelten Linien markieren die drei Umbauten, die sich im Git-Log eindeutig datieren lassen.
Interessant an dieser Kurve ist nicht, dass sie steigt. Interessant ist, wo sie knickt. Der Anstieg beginnt nicht mit dem ersten Blogartikel und auch nicht mit dem fünfzigsten. Er beginnt Mitte Juni – und zu diesem Zeitpunkt fielen drei Umbauten zusammen, die für sich genommen jeweils unspektakulär aussahen.
- Die Ausgangslage: 625 Seiten und niemand sieht sie
- Fundament: Performance ist kein Ranking-Bonus, sondern Eintrittskarte
- Technisches SEO: Die unsichtbaren Blockaden
- i18n: Warum deutsche Slugs unter /en Rankings kosten
- GEO: Auffindbarkeit für Maschinen, die nicht klicken
- Die Content-Maschine und das Orphan-Problem
- Indexierung als eigene Disziplin
- Was schiefging – der unangenehme Teil
- Das Ergebnis in Zahlen
- Was davon auf Ihr Projekt übertragbar ist
Die Ausgangslage: 625 Seiten und niemand sieht sie
Die Website ist eine statisch generierte Astro-Seite, zweisprachig Deutsch und Englisch, mit inzwischen rund 625 statischen Seiten: Serviceseiten, Stadt-Landingpages, ein Glossar mit über 530 Fachbegriffen und derzeit 126 Blogartikel je Sprache.
Diese Zahl ist der erste wichtige Punkt. Viele Projekte scheitern nicht daran, dass sie zu wenig Inhalt haben, sondern daran, dass sie viel Inhalt haben, der technisch nicht auffindbar oder untereinander nicht verbunden ist. Ein statischer Generator produziert HTML in beliebiger Menge – aber ob Google diese Seiten crawlt, indexiert und für relevante Anfragen ausspielt, hängt an ganz anderen Dingen.
Im März und April lag die Kurve praktisch auf der Nulllinie, obwohl bereits Dutzende Artikel online waren. Der Inhalt war also nicht das Problem.
Der Denkfehler, mit dem fast jedes Projekt startet
„Wir brauchen mehr Content." In den ersten drei Monaten war Content das Einzige, was wir produzierten – und die Kurve blieb flach. Was fehlte, war das technische Fundament, über das Google diesen Content überhaupt erreichen und einordnen konnte. Content ohne Auffindbarkeit ist ein Archiv, kein Marketingkanal.
Fundament: Performance ist kein Ranking-Bonus, sondern Eintrittskarte
Die Core Web Vitals sind als direkter Rankingfaktor schwach – das stimmt. Als indirekter Faktor sind sie brutal: Eine langsame Seite wird seltener gecrawlt, hat schlechtere Nutzersignale und verliert bei ansonsten gleichwertigen Wettbewerbern das Rennen. Der Performance-Umbau war deshalb die erste große Baustelle.
Chatbot aus dem kritischen Pfad (5. Juni)
Der KI-Chatbot lud sein JavaScript und sein CSS im kritischen Rendering-Pfad mit. Beides wurde entkoppelt: Logik per Lazy Loading, das Fenster-CSS aus der render-blockierenden components.css herausgelöst, der Chunk-Preload hinter das load-Event geschoben.
Testimonials und i18n aus dem Bundle (6. Juni)
Der Slider und die Sprachlogik hingen im kritischen JS-Bundle jeder einzelnen Seite – auch auf Seiten ohne Slider. Beides wurde herausgelöst und bedarfsgesteuert nachgeladen.
Schriften und Icons (29. Juni)
Manrope wurde auf eine Variable Font umgestellt, ein redundanter Preload der Phosphor-Icon-Schrift entfernt. Die Icon-Schrift selbst wird seitdem als Subset gebaut – nur die tatsächlich verwendeten Glyphen landen in der Auslieferung.
Layout-Stabilität (16. Juni)
Alle Blog-Hero-Bilder bekamen feste width- und height-Attribute gegen Cumulative Layout Shift; fünf besonders große Bilder wurden neu komprimiert.
Die zweite Welle (28. Juli und 11. August)
Render-blockierendes CSS um 28 Prozent reduziert, Bildgewicht um 53 Prozent, das Footer-CSS inline gestellt. Anfang August dann die Bildlast der Startseite vor dem LCP von 1.145 KB auf rund 460 KB gesenkt.
Der wichtigste Effekt dieser Arbeit ist nicht der Wert im Lighthouse-Bericht. Es ist das Crawl-Budget: Ein Googlebot, der eine Seite in 300 statt 1.200 Millisekunden abholt, holt in derselben Zeit viermal so viele Seiten ab. Bei 625 URLs ist das der Unterschied zwischen „in zwei Wochen komplett erfasst“ und „in drei Monaten“.
Technisches SEO: Die unsichtbaren Blockaden
Parallel liefen die klassischen technischen Themen. Die folgende Zeitleiste ist keine Best-Practice-Liste aus einem Lehrbuch, sondern die tatsächliche Reihenfolge, in der die Probleme aufgefallen sind – meist über die Search Console, teilweise über wöchentliche automatisierte Audits.
Sieben Artikel hatten überhaupt kein BlogPosting-Schema. Seitdem generiert das gemeinsame Template das Schema.org-Markup aus dem Frontmatter – händisch geschriebene Schemas können nicht mehr auseinanderlaufen.
Kern-Seiten-Titel auf maximal 60 Zeichen gekürzt, City-Descriptions von zu kurzen Stummeln auf 120–160 Zeichen verlängert. Nebenbei fiel ein doppelt escaptes & auf, das in Snippets sichtbar war.
Die Organisation war als LocalBusiness ausgezeichnet, obwohl es kein Ladenlokal gibt, das Kunden besuchen. Umgestellt auf Organization mit areaServed für die DACH-Region – ehrlicher und für Google widerspruchsfrei.
Einzelne URLs standen in mehreren Sitemap-Chunks gleichzeitig. Jede URL erscheint seitdem in genau einem Chunk.
Zwei Seiten konkurrierten um dieselbe Suchintention rund um „n8n DSGVO". Die Überschneidung wurde aufgelöst, eine Seite auf die Query geschärft, die andere abgegrenzt. Gleichzeitig wurden Titles und Descriptions aller 18 Stadt-Templates neu geschrieben – vorher unterschieden sie sich nur im Städtenamen.
Ein Audit fand 47 interne Links, die ins Leere zeigten – überwiegend Reste aus der Slug-Umstellung. Alle behoben und zusätzlich eine Prüfung in den Build eingebaut, die solche Links künftig beim Bauen abfängt statt erst im Audit.
Experten-Tipp: Kannibalisierung ist teurer als fehlender Content
Keyword-Kannibalisierung fällt in Analysetools selten auf, weil beide Seiten „ranken" – nur eben beide auf Position 14. Der schnellste Test: In der Search Console eine Query filtern und prüfen, ob Google im Zeitverlauf zwischen zwei URLs hin- und herwechselt. Genau dieser Wechsel ist das Symptom.
i18n: Warum deutsche Slugs unter /en Rankings kosten
Der Umbau vom 7. Juni ist im Nachhinein der unterschätzteste Eingriff. Vorher lag der englische Baum unter deutschen Slugs: /en/kontakt, /en/leistungen. Technisch funktionierte das. Für Suchmaschinen war es ein Signalbruch: Eine englischsprachige Seite unter einer deutschen URL passt weder zur Sprache des Inhalts noch zur Erwartung des Nutzers, und die URL ist eines der wenigen Signale, die Google vor dem Rendern der Seite auswerten kann.
Vergleich: Gewachsene i18n vs. zentrale Slug-Map
- URLs: deutsche Slugs unter
/en/– Signalbruch für Sprache und Nutzererwartung - hreflang: im Layout händisch zusammengesetzt, driftet bei jeder neuen Seite
- Sprachumschalter: eigene Logik im Client-Skript, kannte manche Paare nicht
- Redirects: teils in der Konfiguration, teils in der
.htaccess– widersprüchlich
- URLs: echte englische Slugs –
/en/contact,/en/services - hreflang: aus derselben Map generiert, kann strukturell nicht mehr abweichen
- Sprachumschalter: liest dieselbe Map, kennt jedes Paar automatisch
- Redirects: echte 301er, per Skript aus der Map in die
.htaccessgeneriert
Seitdem gibt es eine einzige Datei, in der jedes Slug-Paar steht. Sie speist die Sprachlinks, hreflang, die Canonicals, den Umschalter und die generierten Weiterleitungen. Ein neuer zweisprachiger Artikel bedeutet: eine Zeile ergänzen, Generator laufen lassen, fertig.
Ein Detail aus dieser Umstellung hat uns eine eigene Regel gekostet: Ein Slug-Paar, bei dem die deutsche und die englische Fassung identisch sind, darf nicht in die Map – sonst erzeugt der Generator eine Weiterleitung von /en/blog-x auf /en/blog-x. Eine Endlosschleife, die die Seite für Crawler unerreichbar macht.
GEO: Auffindbarkeit für Maschinen, die nicht klicken
Ein wachsender Teil der Suchanfragen endet heute in einer KI-Antwort statt in einem Klick. Generative Engine Optimization ist deshalb kein Nachfolger von SEO, sondern eine zweite Zielgruppe: Systeme, die Inhalte lesen, zusammenfassen und zitieren – ohne dass ein Mensch die Seite je öffnet. Diese Systeme belohnen andere Dinge als ein klassischer Ranking-Algorithmus.
llms.txt automatisch beim Build
Seit dem 8. Juni erzeugt der Build llms.txt und llms-full.txt aus der Content Collection. Der entscheidende Punkt ist nicht die Datei, sondern die Automatik: Eine händisch gepflegte Liste driftet garantiert vom echten Bestand ab, und eine veraltete Übersicht ist schlechter als gar keine.
Direktantwort-Blöcke (2. August)
Jeder Artikel kann seitdem eine kompakte Antwort von 40 bis 60 Wörtern im Frontmatter tragen. Sie wird sichtbar oberhalb des Textes gerendert und speist gleichzeitig abstract und speakable im Schema – ein Format, das generative Systeme direkt übernehmen können.
Das Glossar als Entitäten-Hub
Über 530 Fachbegriffe mit stabilen Ankern. Jeder Fachbegriff im Fließtext verlinkt dorthin. Das erzeugt ein dichtes Netz aus Begriff-Definition-Beziehungen – genau die Struktur, aus der Sprachmodelle thematische Autorität ableiten.
FAQPage- und HowTo-Schema
Wo ein Artikel ein Glossar mit mindestens drei Einträgen oder eine nummerierte Roadmap enthält, bekommt er zusätzlich das passende strukturierte Schema. Das macht die Antwortstruktur maschinenlesbar, statt sie im Fließtext zu verstecken.
Am 2. August kam eine Maßnahme dazu, die kurzfristig am meisten gebracht hat: die Striking-Distance-Auswertung. Aus der Search Console werden alle Suchanfragen gezogen, bei denen eine Seite auf Position 11 bis 20 steht. Diese Seiten haben das Fundament bereits – ihnen fehlt der letzte Schub. Statt neue Artikel zu schreiben, wurden gezielt interne Links auf genau diese Seiten gesetzt.
Warum Striking Distance der beste Zeiteinsatz ist
Eine Seite von Position 40 auf Position 10 zu bringen, ist Monatsarbeit. Eine Seite von Position 12 auf Position 8 zu bringen, ist oft eine Frage von drei internen Links und einem geschärften Title – und der Unterschied im tatsächlichen Traffic ist um ein Vielfaches größer, weil die Klickrate zwischen Seite zwei und Seite eins nicht linear, sondern sprunghaft verläuft.
Die Content-Maschine und das Orphan-Problem
Im Juli wurden die Blogartikel von einzelnen Seiten-Dateien auf eine Content Collection umgestellt: Jeder Artikel ist seitdem eine Markdown-Datei mit schema-validiertem Frontmatter, das gesamte Rahmen-Markup rendert ein gemeinsames Template. Der Gewinn ist weniger die Schreibgeschwindigkeit als die Unmöglichkeit bestimmter Fehler: Ein Artikel ohne Kategorie, ohne Datum oder mit fehlendem Bild bricht den Build, statt still kaputt live zu gehen.
Das eigentliche Problem war ein anderes. Ein neuer Artikel war von genau einer Seite aus erreichbar – der Blog-Übersicht. Damit ist er eine Orphan Page: in der Sitemap vorhanden, aber ohne internes Linkgewicht.
-
Ausgehende Links reichen nicht
Jeder Artikel verweist auf drei thematisch passende Beiträge. Das hilft dem Leser – dem neuen Artikel selbst hilft es null, weil Linkgewicht in die andere Richtung fließt.
-
Reziprozität als Pflicht
Bei jedem neuen Artikel wird er zusätzlich in mindestens zwei bestehenden Beiträgen je Sprache als verwandter Beitrag eingetragen – bevorzugt in solchen, die selbst noch wenige eingehende Links haben.
-
Fließtext schlägt Related-Block
Wo es inhaltlich trägt, kommt zusätzlich ein Link mitten im Text eines Bestandsartikels. Ein Link im Fließtext mit passendem Ankertext wirkt deutlich stärker als eine Kachel im Fuß der Seite.
-
Messen statt hoffen
Ein Report-Skript listet alle Artikel mit weniger als zwei eingehenden Links. Ein neuer Slug darf dort nach dem Einpflegen nicht mehr auftauchen. Das ist eine Prüfung vor dem Push, kein gutes Gefühl.
Indexierung als eigene Disziplin
Der Punkt, den nach unserer Erfahrung die meisten Projekte unterschätzen: Zwischen „veröffentlicht“ und „in Google“ liegt ein Schritt, den man aktiv gehen kann. Passiv wartet man auf den nächsten Crawl – das dauert bei einer jungen Domain mit schwachem Crawl-Budget Wochen.
Nach jedem Deploy meldet ein Skript die tatsächlich geänderten URLs über die Google Indexing API an. Die URLs ermittelt es selbst aus dem Git-Diff der letzten Commits – nicht aus einer gepflegten Liste, die vergisst, was sich wirklich geändert hat. Für Bing läuft parallel eine IndexNow-Meldung.
Der teure Irrtum
Wir betreiben fünf Service-Accounts und rechneten mit
1.000 URLs/TagFalsch. Das Kontingent gilt pro Google-Cloud-Projekt, nicht pro Dienstkonto. Zwei unserer Bots liegen im selben Projekt und teilen sich eines.
Die Realität
Vier Projekte à rund 200 Anfragen
800 URLs/TagKlingt nach einem Detail. Bei einem Deploy, der 222 Seiten ändert – so geschehen am 8. August –, entscheidet es darüber, ob eine Kampagne an einem Tag durchläuft oder an dreien.
Ein zweiter Fallstrick kostete uns fast einen Umbau: Frisch in der Search Console freigeschaltete Dienstkonten lieferten minutenlang weiter 403 Failed to verify the URL ownership. Die naheliegende Reaktion – die Konfiguration umbauen – wäre falsch gewesen. Die Freigabe braucht schlicht Zeit, um zu propagieren.
Was schiefging – der unangenehme Teil
Ein Werkstattbericht ohne Werkstattschäden ist Werbung. Diese fünf Vorfälle haben jeweils eine feste Regel im Projekt hinterlassen.
Literale Sternchen auf 16 Seiten
Markdown wird innerhalb roher HTML-Blöcke nicht geparst. Beim Umbau von Textlisten in visuelle Komponenten wanderte Prosa mit **Fettung** in <p>-Tags – und stand danach wörtlich mit Sternchen auf 16 Blogseiten live. Regel seitdem: Beim Verschieben in rohes HTML wird die Auszeichnung mit umgeschrieben, und der Build prüft auf verbliebene Sternchen.
23 Artikel mit ungültigen Listen
Eine Roadmap-Komponente verwendete <li>-Elemente in einem <div> statt in einer Liste. Optisch identisch, für Screenreader kaputt – und im Barrierefreiheits-Audit zwei kritische Fehler auf 23 Seiten. Regel seitdem: Der Container ist ein <ol>, und eine Prüfung vor dem Commit zählt die Verstöße.
Der rote Deploy durch einen erfundenen Icon-Namen
Ein Icon-Name, den es im Katalog nicht gibt. Lokal lief der Build grün, weil der schnelle Befehl die Icon-Prüfung überspringt – in der CI brach genau dieser Schritt ab. Regel seitdem: Vor jedem Push läuft exakt der Befehl, den auch die CI ausführt. Ein „geht bei mir" ohne identischen Build ist keine Aussage.
Zwei Lockfiles, ein Deploy-Abbruch
Eine Sicherheitsanpassung an einer Abhängigkeit wurde nur an einer von zwei Stellen nachgezogen. Die aufgelöste Version stimmte, nur der aufgezeichnete Versionsbereich wich ab – die CI brach mit einem Lockfile-Konflikt ab und riss einen unbeteiligten Commit mit. Regel seitdem: Wer die Abhängigkeits-Overrides anfasst, zieht beide Lockfiles nach.
Der lokale Deploy, der eine Seite auf 404 setzte
Der schlimmste Vorfall. Ein lokales Deploy-Skript meldete Erfolg, auch wenn die Übertragung fehlschlug, und glich seinen Stand nicht gegen den Hauptbranch ab. Am 25. Juli überschrieb es mit einem alten lokalen Stand einen frischen Deploy – eine gerade veröffentlichte Seite war danach wieder 404. Regel seitdem: Es gibt keinen lokalen Deploy-Weg mehr. Ausschließlich CI, mit anschließendem Live-Check gegen den Origin.
Der gemeinsame Nenner dieser fünf Fälle ist bemerkenswert: Kein einziger war ein SEO-Fehler. Es waren Prozessfehler. Und jeder von ihnen hat für Tage oder Wochen Sichtbarkeit gekostet – entweder weil eine Seite nicht erreichbar war, oder weil sie fehlerhaft ausgeliefert wurde.
Das Ergebnis in Zahlen
Alle folgenden Werte stammen aus der Search-Console-API für die Domain-Property sc-domain:pragma-code.de mit dataState: final. Der Vergleich stellt die ersten 28 Tage nach dem Livegang den letzten 28 Tagen bis zum 11. August 2026 gegenüber.
Impressionen
1.531 → 45.443 in 28 Tagen. Das ist knapp das 30-Fache. In Summe über den gesamten Zeitraum: 101.478.
Klicks
9 → 285 in 28 Tagen, rund das 32-Fache. Gesamtzeitraum: 580 Klicks.
Suchanfragen
57 → 2.476 unterschiedliche Queries mit mindestens einer Impression. Die aussagekräftigste Zahl von allen.
Sichtbare Seiten
586 einzelne URLs erschienen in den letzten 28 Tagen mindestens einmal in den Suchergebnissen.
Zur Einordnung gehören zwei ehrliche Anmerkungen. Erstens: Die durchschnittliche Position liegt bei 22,5 – das ist Seite zwei bis drei. Diese Domain hat Sichtbarkeit gewonnen, aber die Ernte in Form von Klicks steht überwiegend noch aus. Die Klickrate von 0,6 Prozent ist genau das, was man auf diesen Positionen erwartet.
Zweitens: Die Kennzahl, auf die wir am meisten geben, sind nicht die Impressionen, sondern die 2.476 unterschiedlichen Suchanfragen. Impressionen kann ein einzelner viral gegangener Artikel erzeugen. Für Tausende verschiedene Suchanfragen sichtbar zu sein, bedeutet, dass Google die Domain thematisch einordnen kann und ihr in einem breiten Themenfeld zutraut, relevant zu sein. Das ist das Fundament, auf dem Positionen wachsen – und der Grund, warum die Klickkurve in der Grafik der Impressionskurve mit Verzögerung folgt.
Was davon auf Ihr Projekt übertragbar ist
Die konkreten Maßnahmen sind an unseren Stack gebunden. Die Reihenfolge ist es nicht.
Zuerst das Fundament, dann der Inhalt. Drei Monate Content auf einer technisch blockierten Seite haben bei uns nichts bewegt. Dieselben Inhalte auf einem sauberen Fundament haben die Kurve gedreht. Wer beides parallel machen muss, priorisiert das Fundament.
Automatisieren, was driften kann. hreflang, Sitemaps, strukturierte Daten, Weiterleitungen, llms.txt – alles, was von Hand gepflegt wird, weicht früher oder später vom echten Bestand ab. Generieren Sie es aus einer Quelle.
Indexierung ist eine aktive Handlung. Veröffentlichen ist nicht dasselbe wie indexiert werden. Der Weg über die Indexing API verkürzt bei jungen Domains Wochen auf Stunden.
Ernten Sie, was fast reif ist. Die Striking-Distance-Auswertung bringt pro investierter Stunde mehr als jeder neue Artikel – solange Seiten auf den Positionen 11 bis 20 liegen.
Jede Panne wird eine Regel. Der eigentliche Fortschritt in diesem Projekt liegt nicht in den Maßnahmen, sondern in den Prüfungen, die aus den Fehlern entstanden sind und dieselbe Klasse Fehler künftig vor dem Livegang abfangen.
Quick-Check: Ihr Weg zur Sichtbarkeit
Wenn Sie wissen möchten, welche dieser Punkte auf Ihrer Domain offen sind, ist ein technisches SEO-Audit der schnellste Einstieg. Wie sich die Prioritäten verschieben, wenn ein Großteil der Suchanfragen in KI-Antworten endet, beschreibt der Masterplan für GEO statt SEO. Und wer viele strukturgleiche Seiten betreibt – Standorte, Kategorien, Anwendungsfälle –, findet die Fallstricke im Leitfaden zu Programmatic SEO.
Haben Sie Fragen zu Sichtbarkeit, SEO und GEO?
Kostenlose Erstberatung vereinbarenUnsere Expertise vor Ort
Wir sind Ihr digitaler Partner – regional verankert und überregional erfolgreich.
Haben Sie eine Vision?
Lassen Sie uns gemeinsam prüfen, wie wir Ihre Idee zum Fliegen bringen.
Jetzt kostenloses Strategiegespräch buchenErweitertes Fachglossar
hreflang
Ein HTML- bzw. HTTP-Header-Attribut, das Suchmaschinen mitteilt, welche Sprach- und Regionsvariante einer Seite für welche Zielgruppe gedacht ist. Fehlerhafte oder nicht reziproke hreflang-Angaben führen dazu, dass Google die falsche Sprachfassung ausliefert oder Varianten als Duplikate wertet.
Striking Distance
Suchanfragen, für die eine Seite bereits auf den Positionen 11 bis 20 rankt und damit knapp außerhalb der ersten Ergebnisseite liegt. Weil das Fundament hier bereits steht, erzeugen gezielte interne Links und Textergänzungen auf diesen Seiten deutlich schneller Sichtbarkeit als neue Inhalte.
Orphan Page
Eine Seite, auf die aus dem eigenen Seitenbestand kaum oder gar nicht verlinkt wird. Sie ist zwar über die Sitemap auffindbar, erhält aber kaum internes Linkgewicht und wird von Crawlern seltener besucht und langsamer aktualisiert.
Google Indexing API
Eine Programmierschnittstelle, über die geänderte oder neue URLs aktiv bei Google zur Indexierung angemeldet werden, statt auf den nächsten Crawl zu warten. Das Tageskontingent von rund 200 Anfragen gilt pro Google-Cloud-Projekt, nicht pro Dienstkonto.
IndexNow
Ein offenes Benachrichtigungsprotokoll, mit dem Websites geänderte URLs an teilnehmende Suchmaschinen wie Bing und Yandex melden. Eine einzige Meldung wird an alle beteiligten Suchmaschinen weitergereicht.
Keyword-Kannibalisierung
Der Zustand, in dem mehrere eigene Seiten auf dieselbe Suchintention optimiert sind und dadurch miteinander konkurrieren. Google verteilt Relevanzsignale auf die Kandidaten, wechselt die rankende URL und keine der Seiten erreicht die Position, die eine gebündelte Seite erreichen würde.
