Unsere fünf Produkt-Workflows waren für den ersten Crawl vollständig unsichtbar.
Nicht schlecht platziert, sondern abwesend. Jeder Produktname, jeder Nutzentitel
und jede Beschreibung wurde nach dem Laden der Seite von einem internen Endpunkt
geholt und per innerHTML ins DOM geschrieben. Das HTML, das ein Crawler
erhielt, enthielt daher genau eine relevante Zeichenkette:
Loading Platform Architecture....
Wir haben die Website so neu gebaut, dass Inhalte serverseitig gerendert werden. Das haben wir dabei gelernt.
Das Versagen war messbar, und es war null
Die Prüfung braucht einen einzigen Befehl:
curl -s https://archmir.com/platform/expertarch | grep -c "Expert Level Reasoning Layer"
Vor dem Umbau gab das 0 zurück. Die Seite hatte einen Titel, eine Beschreibung
und Open-Graph-Tags, alle serverseitig durch Textersetzung in einer Vorlage
eingefügt, aber keinen Fließtext. Die Metadaten beschrieben eine Seite, deren
Inhalt erst existierte, wenn JavaScript lief.
Das wiegt heute schwerer als früher. Der Googlebot indexiert in zwei Durchgängen: Der erste liest rohes HTML, alles Weitere, das JavaScript benötigt, wird für den Web Rendering Service eingereiht, wo es Stunden oder Wochen warten kann. Crawler, die nie JavaScript ausführen, darunter Social-Media-Vorschauen und eine wachsende Zahl von KI-Rechercheagenten, sehen den Inhalt überhaupt nie.
Was wir geändert haben
Der Inhalt wanderte von einer clientseitigen Anfrage in Server Components. Das interaktive Verhalten blieb, hängt sich nun aber an Markup, das bereits im HTML steht, statt es selbst zu erzeugen.
| Vorher | Nachher |
|---|---|
Katalog vom Endpunkt /api/content/platform geholt, per innerHTML eingefügt | Vom Server gerendert; im initialen HTML enthalten |
Produktseiten zur Laufzeit von einer Funktion _renderIsolationMode() gebaut | Zur Build-Zeit statisch erzeugt, eine Datei je Produkt und Sprache |
Sprache über einen Query-Parameter ?lang= gewechselt | Getrennte, indexierbare Pfade, mit hreflang dazwischen |
| Ein einziges Open-Graph-Bild für jede URL | Eine generierte Karte pro Route |
Die Überschriftenstruktur begann mit h3, ohne h2 darüber | Ein h1, dann eine echte h2/h3-Hierarchie |
Die interaktiven Teile, also Tab-Wechsel, Scroll-Effekte, Videowiedergabe und das Kontaktformular, sind Client-Komponenten, die über serverseitig gerendertem Markup eingehängt werden. Nutzer verlieren nichts.
Drei Dinge, die nicht offensichtlich waren
Inhalte hinter opacity: 0 zu verstecken ist ein echtes Risiko. Unsere
Scroll-Animationen starten jeden Abschnitt unsichtbar und blenden ihn per
JavaScript ein. Der Googlebot rendert JavaScript und würde ihn schließlich sehen,
ein Client ohne JavaScript sähe jedoch eine leere Seite. Ein <noscript>-Block,
der die Animation neutralisiert, kostet nichts und beseitigt diesen Fehlerfall
vollständig.
Eine URL in der robots.txt zu sperren entfernt sie nicht aus dem Index. Wir
hatten geplant, die alten ?lang=-URLs zu sperren. Das wäre verkehrt herum
gewesen: Eine URL, die ein Crawler nicht abrufen kann, ist eine URL, deren
Weiterleitung er nie entdecken kann, die alte Adresse wäre also unbefristet im
Index geblieben. Weiterleitungen müssen crawlbar sein, um zu wirken.
KI-Crawler brauchen eine ausdrückliche Einladung. Google-Extended und
Applebot-Extended sind Opt-out-Tokens für KI-Grounding. Nichts zu sagen
überlässt die Entscheidung einer Voreinstellung. Wenn Ihre Dokumentation für
generative Suchsysteme erreichbar sein soll, führen Sie diese unter Allow auf.
Der Teil, der sich nicht automatisieren lässt
Rendering-Strategie, strukturierte Daten und Core Web Vitals sind Engineering-Probleme, und Engineering-Probleme haben bestimmbare Lösungen. Was keines von ihnen ersetzt, ist, etwas Konkretes und Überprüfbares zu sagen zu haben. Genau deshalb sind die Zahlen in diesem Beitrag die, die wir auf unserer eigenen Website gemessen haben, und nicht Benchmarks aus fremden Quellen.