JavaScript Rendering: Was Crawler sehen, bevor Ihre App startet

Suchmaschinen holen zuerst Ihr HTML ab und rendern JavaScript später, in einem separaten Durchlauf mit seiner eigenen Warteschlange. Alles, was erst nach der Hydration existiert, ist während dieses ersten Durchlaufs unsichtbar, und die Verzögerung bis zum zweiten Durchlauf wird in Tagen bei vielen Seiten gemessen. KI-Crawler sind noch strenger: Die meisten führen kein JavaScript aus, sodass das rohe HTML die gesamte Seite ist. Das macht die Renderparität zur Frage, die beantwortet werden muss. Trägt Ihr ausgeliefertes HTML denselben Titel, H1, Canonical, Meta-Beschreibung, strukturierte Daten und Textkörper wie das gerenderte DOM? Auf einer serverseitig gerenderten Seite ist das bei Konstruktion der Fall. Auf einer clientseitig gerenderten App ist das HTML oft nur ein Shell aus einem Div und einem Skript-Tag, und die Paritätslücke ist total. Ein Shell ist auch das, was unser eigener Engine als dünnen Inhalt kennzeichnet, weil von außen die beiden nicht unterscheidbar sind. Ein 40-Wort-HTML-Dokument ist ein 40-Wort-Dokument, egal ob die restlichen 2,000 Wörter später ankommen oder nie. Die unten aufgeführten Prüfungen holen das rohe HTML, vergleichen es mit einer gerenderten Version desselben Seiten-Elements Stück für Stück und berichten, wo die beiden auseinandergehen. Wo sie es tun, verschieben Sie dieses Element in die Serverantwort, anstatt Crawlern zu bitten, darauf zu warten.