{"content_id":"nz3psdk2a0","slug":"low-involvement-web-static-generation-html-cache","locale":"de","schema_type":"TechArticle","category":"knowledge_base","category_name":"Wissensdatenbank","title":"Low-Involvement-Web: Statische Generierung und HTML-Cache","summary":"Bei der technischen Planung des Low-Involvement-Web müssen sowohl der Hauptinhalt im initialen HTML als auch der HTML-Cache des CDN geprüft werden. Der TTFB-Wert von 0.8 Sekunden dient als Richtwert für Leistungsverbesserungen. Auch der Geltungsbereich des Caches und seine Aktualisierung nach Änderungen müssen eingeplant werden.","sponsorship_disclosure":null,"affiliate_disclosure":null,"commerce_disclosure":null,"author":{"name":"injoys","url":"https://injoys.com/ko/about"},"key_points":["Wenn das initiale HTML den wesentlichen Hauptinhalt enthält, lässt sich die Abhängigkeit von der Ausführung von JavaScript verringern.","Google führt JavaScript aus. Die Verwendung von React allein lässt daher nicht auf ein Scheitern des Crawlings schließen.","Ein TTFB-Wert von höchstens 0.8 Sekunden dient als Richtwert für Leistungsverbesserungen und bezeichnet nicht die gesamte Ladezeit der Seite.","Das Cloudflare CDN speichert HTML standardmäßig nicht im Cache. Daher müssen die Cache-Regeln für öffentliche Seiten geprüft werden.","Für den HTML-Cache müssen Login-Seiten ausgeschlossen und Regeln zur Aktualisierung nach Inhaltsänderungen festgelegt werden."],"content_markdown":"Um das Crawling von Websites mit geringem Involvement zu erleichtern, muss das initiale HTML den zentralen Seiteninhalt enthalten. Für öffentliche Inhalte sind statische Generierung und das Caching von HTML im CDN sinnvoll. Eine TTFB von 0.8 Sekunden allein garantiert jedoch keine Sichtbarkeit in der Suche.\n\nDie Angabe zur TTFB basiert auf der am 18. November 2025 aktualisierten Dokumentation von web.dev.\n\n## Technische Voraussetzungen, die bei Websites mit geringem Involvement zuerst zu prüfen sind\n\nIn diesem Artikel bezeichnet der Begriff Websites mit geringem Involvement solche Websites, auf denen benötigte Informationen kurz nachgeschlagen werden. Rendering und Übertragungsgeschwindigkeit gehören bei solchen Websites zur technischen Prüfung. Unterschiede in der Sichtbarkeit in der Suche lassen sich jedoch nicht allein durch diese beiden Punkte erklären.\n\nBeim Crawling ruft ein Bot Seiten ab. Bei der Indexierung werden die abgerufenen Inhalte für die Suche verarbeitet. Google erklärt, dass nicht alle gecrawlten Seiten in den Index aufgenommen werden. [Google-Leitfaden zum Crawling-Budget](https://developers.google.com/crawling/docs/crawl-budget)\n\n| Prüfpunkt | Was zu prüfen ist | Zu lösendes Problem |\n| --- | --- | --- |\n| Initiales HTML | Ob Titel und zentraler Seiteninhalt in der Antwort enthalten sind | Abhängigkeit von zusätzlicher Codeausführung, um den Inhalt zu lesen |\n| Rendering | Ob die Inhalte nach der Ausführung von JavaScript korrekt erscheinen | Fehlende Inhalte durch Ausführungsfehler oder Blockierungen |\n| TTFB | Zeit bis zum Eintreffen der ersten Antwort | Verzögerungen beim Verbindungsaufbau und bei der Serverantwort |\n| HTML-Cache | Ob öffentliche Dokumente im CDN wiederverwendet werden | Aufwand durch wiederholte Anfragen an den Ursprungsserver |\n| Indexierungsstatus | Wie Google die betreffende URL verarbeitet hat | Verwechslung von erfolgreichem Crawling und Aufnahme in den Suchindex |\n\n## Warum React-Seiten als leeres HTML erscheinen\n\nDas initiale HTML einer React-Seite hängt von der Implementierung ab. Wenn der Hauptinhalt im Browser erzeugt wird, spricht man von CSR. Bei diesem Verfahren kann die erste Antwort nur ausführbaren Code und keinen Hauptinhalt enthalten.\n\nGoogle führt JavaScript mithilfe von Chromium aus. Nach dem Crawling kann eine Seite auf das Rendering warten. Blockierte Seiten oder Dateien können vom Rendering ausgeschlossen werden. Auch führt nicht jeder Bot JavaScript aus. [Google-Grundlagen zu JavaScript SEO](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)\n\nBeurteilen Sie den Crawling-Status deshalb nicht allein danach, ob die Seite korrekt angezeigt wird. Prüfen Sie zuerst, ob die initiale Antwort den Hauptinhalt enthält. Das von Google gerenderte Ergebnis können Sie mit der URL-Prüfung in der Search Console kontrollieren.\n\n## Statische Generierung und serverseitiges Rendering im Vergleich\n\nWie das HTML erzeugt wird, lässt sich danach auswählen, wie der öffentliche Hauptinhalt aktualisiert wird. Bei der statischen Generierung wird HTML vor einer Anfrage erstellt. Beim serverseitigen Rendering erzeugt der Server das HTML, wenn eine Anfrage eingeht. Diese Verfahren lassen sich auch mit React nutzen. [web.dev-Leitfaden zu Rendering-Verfahren](https://web.dev/articles/rendering-on-the-web)\n\n| Verfahren | Zeitpunkt der HTML-Erzeugung | Geeignete Einsatzsituationen | Im Betrieb zu prüfen |\n| --- | --- | --- | --- |\n| Clientseitiges Rendering CSR | Wenn JavaScript im Browser ausgeführt wird | Ansichten mit vielen Nutzerinteraktionen | Erforderliche Ausführungen und Anfragen bis zur Anzeige des Hauptinhalts |\n| Statische Generierung SSG | Beim Build oder bei der Erstellung von Inhalten | Öffentliche Dokumente, die allen Besuchern denselben Inhalt zeigen | Neugenerierung und Bereitstellung nach Änderungen |\n| Serverseitiges Rendering SSR | Bei der Verarbeitung einer Seitenanfrage | Ansichten, deren aktuelle Inhalte bei jeder Anfrage zusammengestellt werden | Zeit für Datenabfragen und HTML-Erzeugung |\n| Vorab-Rendering | Wenn die App vor der Bereitstellung ausgeführt wird, um HTML zu erzeugen | Wenn der initiale Hauptinhalt einer bestehenden App vorab bereitgestellt werden soll | JavaScript, das für die anschließenden Funktionen benötigt wird |\n\nStatische Generierung und CDN erfüllen unterschiedliche Aufgaben. Bei der statischen Generierung geht es darum, wann HTML erzeugt wird. Ein CDN dient der Auslieferung und Wiederverwendung von Inhalten. Auch serverseitig erzeugtes HTML kann unter passenden Bedingungen im CDN gecacht werden.\n\n## Was bedeutet eine TTFB von 0.8 Sekunden?\n\nTTFB ist die Zeit vom Beginn der Navigation bis zum ersten Byte der Antwort. web.dev nennt für die meisten Websites **höchstens 0.8 Sekunden** als groben Zielwert. Das ist nicht die Zeit bis zur vollständigen Anzeige der Seite. TTFB selbst gehört auch nicht zu den Core Web Vitals. [web.dev-Erklärung zu TTFB](https://web.dev/articles/ttfb)\n\nTTFB umfasst auch Verzögerungen außerhalb der internen Serververarbeitung. Bei der DNS-Abfrage wird die Verbindungsadresse einer Domain ermittelt. Auch der Aufbau von TCP- und TLS-Verbindungen kann Zeit benötigen. Weiterleitungen an eine andere Adresse wirken sich ebenfalls aus.\n\n- Zeit für DNS-Abfrage und Verbindungsvorbereitung\n- Übertragungszeit von Anfrage und Antwort über das Netzwerk\n- Zeit für Datenabfragen und HTML-Erzeugung auf dem Ursprungsserver\n- Zeit für Weiterleitungen vor der ersten Antwort\n\nAllein aus dem Standort eines Servers in Seoul lässt sich nicht schließen, dass die TTFB mehr als 0.8 Sekunden beträgt. Das Ergebnis hängt vom Zugriffsort und davon ab, ob Verbindungen wiederverwendet werden. Die Crawler von Google verwenden hauptsächlich IP-Adressen aus den USA. Sie können jedoch auch über IP-Adressen aus anderen Ländern zugreifen. [Technische Eigenschaften der Google-Crawler](https://developers.google.com/crawling/docs/crawlers-fetchers/overview-google-crawlers?hl=en)\n\nAnhaltende Antwortverzögerungen beeinflussen die Crawling-Kapazität von Google. Auch Serverfehler können zu einem geringeren Crawling-Umfang führen. Es gibt jedoch keine Regel, nach der das Crawling unterbrochen wird, sobald 0.8 Sekunden einmal überschritten werden. Auch die Seitenqualität und die Aktualisierungshäufigkeit beeinflussen den Crawling-Bedarf. [Google-Leitfaden zum Crawling-Budget](https://developers.google.com/crawling/docs/crawl-budget)\n\n## Warum der HTML-Cache im CDN geprüft werden muss\n\nDas Cloudflare CDN speichert HTML standardmäßig nicht im Cache. Auch wenn Bilder oder CSS gecacht werden, muss das Dokument mit dem Hauptinhalt gesondert geprüft werden. Das Standardverhalten anderer CDNs finden Sie in der Dokumentation des jeweiligen Dienstes.\n\n\u003e Das Cloudflare CDN speichert HTML oder JSON standardmäßig nicht im Cache.\n\u003e\n\u003e Cloudflare, Standardverhalten des Caches\n\nDieser Satz bedeutet, dass HTML und JSON standardmäßig nicht zum Caching vorgesehen sind. Öffentliches HTML kann über Cache Rules für das Caching freigegeben werden. Ob es tatsächlich gespeichert wird, hängt auch von Bedingungen wie Antwort-Headern und Cookies ab. [Cloudflare-Standardverhalten des Caches](https://developers.cloudflare.com/cache/concepts/default-cache-behavior/)\n\nEin Cache ermöglicht es, gespeicherte Antworten wiederzuverwenden. Die Anbindung an ein CDN bedeutet nicht, dass alle Dokumente sofort weltweit repliziert werden. Cloudflare speichert Inhalte in dem Rechenzentrum im Cache, das die Anfrage verarbeitet. Bei Anfragen nach Inhalten, die nicht im Cache liegen, kann ein Abruf vom Ursprungsserver erforderlich sein. [Cloudflare-Einstieg in das Caching](https://developers.cloudflare.com/cache/get-started/)\n\nSchließen Sie personalisierte Seiten aus, wenn Sie Cache-Regeln auf öffentliches HTML anwenden. Cloudflare warnt davor, dass durch das Caching von dynamischem HTML Informationen anderer Personen ausgeliefert werden können. Speichern Sie Login- oder Kontoseiten nicht im Cache. [Cloudflare-Hinweise zu Cache Everything](https://developers.cloudflare.com/cache/how-to/cache-rules/examples/cache-everything/)\n\n## Kriterien für das Caching je nach Seitentyp\n\nAusgangspunkt für den Umfang des Cachings ist die Frage, ob Besucher denselben Inhalt sehen. Öffentliche Beschreibungstexte eignen sich gut für eine gemeinsame Wiederverwendung. Antworten, deren Inhalt sich je nach Anmeldestatus unterscheidet, müssen gesondert behandelt werden.\n\n| Seiteneigenschaft | Zu prüfende Konfiguration | Zusätzlich zu prüfen |\n| --- | --- | --- |\n| Derselbe Beschreibungstext für alle Besucher | Statische Generierung und Caching von öffentlichem HTML | Neugenerierung und Cache-Aktualisierung nach Änderungen |\n| Öffentlicher Hauptinhalt mit häufig wechselnden Zahlenwerten | Aktualisierung von Hauptinhalt und veränderlichen Daten getrennt behandeln | Bezugszeitpunkt der Werte und Anzeige bei Fehlern |\n| Aktuelle öffentliche Informationen zum Anfragezeitpunkt erforderlich | Serverseitiges Rendering und bedingtes Caching prüfen | Zulässige Verzögerung der Informationen |\n| Login-, Konto- und Zahlungsseiten | Vom gemeinsamen HTML-Cache ausschließen | Authentifizierungs-Cookies und nutzerspezifische Antworten |\n| Öffentliche Dokumente in mehreren Sprachen | Sprachspezifische URLs und Cache jedes Dokuments | Verknüpfung der Übersetzungen und sprachspezifische Aktualisierung |\n\nWenn Echtzeitdaten später geladen werden, lässt sich ein statischer Hauptinhalt leichter beibehalten. Verschieben Sie jedoch nicht sämtliche für die Suche wesentlichen Inhalte auf einen späteren Ladezeitpunkt. Das kann dem Zweck widersprechen, initiales HTML bereitzustellen.\n\n## Häufige Fehler und Prüfkriterien\n\nWer Ergebnisse nur anhand von Technologienamen oder Einstellungsseiten beurteilt, übersieht leicht Fehler. Prüfen Sie das tatsächliche HTML zusammen mit den Antwort-Headern. Die folgenden Zustände müssen voneinander unterschieden werden.\n\n| Häufige Annahme | Zu prüfendes Kriterium |\n| --- | --- |\n| Suchbots können React-Websites nicht lesen | Initiales HTML und das Rendering-Ergebnis von Google |\n| Bei einer TTFB von 0.8 Sekunden ist auch die gesamte Seite sichtbar | Zeit von der ersten Antwort bis zur Anzeige des Hauptinhalts |\n| Das CDN ist angebunden, also wird auch HTML gecacht | Cache-Status der HTML-Anfrage |\n| Eine statische Datei enthält immer die neuesten Inhalte | Letzter Erstellungszeitpunkt und bereitgestellter Inhalt |\n| Eine schnelle Antwort bedeutet, dass auch die Aufnahme in den Suchindex abgeschlossen ist | Indexierungsstatus in der Search Console |\n| Ein einzelner Cache-Treffer reicht aus, um die weltweite Geschwindigkeit zu beurteilen | Messergebnisse nach Zugriffsregion und Cache-Trefferstatus |\n\n`CF-Cache-Status` von Cloudflare ist ein Header, der den Cache-Status anzeigt. `HIT` bedeutet, dass die Antwort im Cache gefunden wurde. `MISS` bedeutet, dass sie zum Zeitpunkt der Anfrage nicht im Cache lag und vom Ursprungsserver abgerufen wurde. `DYNAMIC` bezeichnet einen Zustand, in dem die Antwort nicht als cachefähig behandelt wurde. [Cloudflare-Erklärung zu Cache-Antworten](https://developers.cloudflare.com/cache/concepts/cache-responses/)\n\n## Cache-Aktualisierung nach Inhaltsänderungen\n\nBei statischen Dateien und CDN-Caches muss auch der Ablauf zur Übernahme von Änderungen geplant werden. Selbst wenn das Original geändert wurde, werden alte Inhalte ausgeliefert, solange der bisherige Cache bestehen bleibt. Wenn HTML und JSON gemeinsam veröffentlicht werden, müssen auch die Inhalte beider Formate übereinstimmen.\n\nDie folgende Prüfreihenfolge gilt, wenn Dokumente und Datendateien gemeinsam betrieben werden.\n\n1. Legen Sie die Änderungen in den Quelldaten fest.\n2. Generieren Sie HTML und Datendateien aus demselben Änderungsstand neu.\n3. Stellen Sie die neuen Dateien bereit und aktualisieren Sie anschließend den Cache der geänderten URLs.\n4. Rufen Sie jede URL erneut ab und prüfen Sie, ob die geänderten Inhalte übereinstimmen.\n\nCloudflare empfiehlt, den Cache für einzelne URLs zu löschen. Beim Löschen des Caches werden gespeicherte Antworten entfernt. Statisches HTML muss separat neu erzeugt werden. Verbinden Sie deshalb die Dateierzeugung und die Cache-Aktualisierung im selben Bereitstellungsablauf. [Cloudflare-Leitfaden zum Löschen des Caches](https://developers.cloudflare.com/cache/how-to/purge-cache/)\n\nLegen Sie die Aktualisierungsintervalle danach fest, welche Verzögerung die Inhalte zulassen. Für Beschreibungstexte und Echtzeitwerte muss nicht derselbe Rhythmus gelten. Eine kurze Cache-Gültigkeitsdauer allein löst nicht alle Aktualisierungsprobleme.\n\n## hreflang-Kriterien für mehrsprachige Websites\n\n`hreflang` verknüpft die sprach- und regionsspezifischen Adressen desselben Inhalts. Es erstellt keine Übersetzungen. Es hilft Google, die passende Sprachversion für Besucher zu finden.\n\n| Implementierungsort | Art der Angabe | Bei der Auswahl zu prüfen |\n| --- | --- | --- |\n| HTML | Links zu alternativen Sprachversionen im `head` des Dokuments angeben | Ob die Verwaltung in den jeweiligen Seitenvorlagen möglich ist |\n| HTTP-Header | Angabe im `Link`-Header der Antwort | Ob die Header auf dem Server verwaltet werden können |\n| Sitemap | Beziehungen zwischen sprachspezifischen URLs in der Sitemap angeben | Ob die Dokumentliste zentral verwaltet werden kann |\n\nGoogle behandelt diese Verfahren gleichwertig. Die Angaben müssen daher nicht ausschließlich im HTML stehen. Jedes Sprachdokument muss auf sich selbst und auf die alternativen Sprachversionen verweisen. Prüfen Sie auch die Verknüpfungen zwischen den einander entsprechenden Seiten. [Google-Leitfaden zu mehrsprachigen Seiten](https://developers.google.com/search/docs/specialty/international/localized-versions)\n\n## Reihenfolge zur Prüfung nach der Bereitstellung\n\nPrüfen Sie nach der Bereitstellung die Auslieferung des Hauptinhalts und das Cache-Verhalten getrennt. Halten Sie bei Geschwindigkeitsmessungen auch die Messregion und den Cache-Status fest. Mit der folgenden Prüfreihenfolge lassen sich Problemstellen leichter eingrenzen.\n\n1. Prüfen Sie die Antwort des HTML-Dokuments in den Entwicklertools des Browsers. Sehen Sie nach, ob der zentrale Seiteninhalt in der Antwort enthalten ist.\n2. Prüfen Sie das gerenderte HTML mit der URL-Prüfung in der Search Console. Kontrollieren Sie den tatsächlichen Indexierungsstatus zusätzlich separat.\n3. Prüfen Sie die Cache-Header der HTML-Antwort. Lesen Sie bei Cloudflare den Wert von `CF-Cache-Status`.\n4. Messen Sie dasselbe Dokument aus den wichtigsten Zugriffsregionen. Unterscheiden Sie zwischen Anfragen ohne Cache-Treffer und solchen mit Cache-Treffer.\n5. Prüfen Sie nach einer Inhaltsänderung, ob die Aktualisierung übernommen wurde. Kontrollieren Sie auch, ob Login-Seiten vom Cache ausgeschlossen sind.\n\nCloudflare warnt davor, dass zu weitreichendes Caching von dynamischem HTML die Anmeldung beeinträchtigen kann. Speichern Sie Login-Formulare und Seiten für authentifizierte Nutzer nicht im Cache. Prüfen Sie nach Änderungen auch, ob die Authentifizierungs-Cookies erhalten bleiben. [Cloudflare-Leitfaden zu Anmeldeproblemen](https://developers.cloudflare.com/cache/troubleshooting/dynamic-content-and-login-issues/)\n\n## Implementierungsvorgaben für die Programmierung mit KI\n\nFordern Sie von der KI neben bestimmten Technologien auch überprüfbare Ergebnisse an. Hilfreich ist es, die Inhalte des initialen HTML und den Umfang der Cache-Ausschlüsse ausdrücklich festzulegen. Der folgende Text ist eine Beispielanfrage für die Erstellung öffentlicher Wissensseiten.\n\n```text\nNehmen Sie den zentralen Inhalt öffentlicher Wissensseiten in das initiale HTML auf.\nPrüfen Sie für öffentliche Dokumente vorrangig die statische Generierung.\nErläutern Sie die Aktualisierung veränderlicher Daten gesondert.\nPrüfen Sie, ob das CDN HTML im Cache speichert.\nSchließen Sie Login-, Konto- und Zahlungsseiten vom gemeinsamen Cache aus.\nVerknüpfen Sie bei Inhaltsänderungen die Neugenerierung statischer Dateien mit der Cache-Aktualisierung.\nRichten Sie bei mehrsprachigen Seiten hreflang-Verknüpfungen ein.\nGeben Sie an, wie das initiale HTML, der Cache-Status und die Übernahme von Änderungen geprüft werden können.\n```","content_html":"\u003cp\u003eUm das Crawling von Websites mit geringem Involvement zu erleichtern, muss das initiale HTML den zentralen Seiteninhalt enthalten. Für öffentliche Inhalte sind statische Generierung und das Caching von HTML im CDN sinnvoll. Eine TTFB von 0.8 Sekunden allein garantiert jedoch keine Sichtbarkeit in der Suche.\u003c/p\u003e\n\u003cp\u003eDie Angabe zur TTFB basiert auf der am 18. November 2025 aktualisierten Dokumentation von web.dev.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#technische-voraussetzungen-die-bei-websites-mit-geringem-involvement-zuerst-zu-pr%C3%BCfen-sind\" class=\"anchor\" id=\"technische-voraussetzungen-die-bei-websites-mit-geringem-involvement-zuerst-zu-prüfen-sind\"\u003e\u003c/a\u003eTechnische Voraussetzungen, die bei Websites mit geringem Involvement zuerst zu prüfen sind\u003c/h2\u003e\n\u003cp\u003eIn diesem Artikel bezeichnet der Begriff Websites mit geringem Involvement solche Websites, auf denen benötigte Informationen kurz nachgeschlagen werden. Rendering und Übertragungsgeschwindigkeit gehören bei solchen Websites zur technischen Prüfung. Unterschiede in der Sichtbarkeit in der Suche lassen sich jedoch nicht allein durch diese beiden Punkte erklären.\u003c/p\u003e\n\u003cp\u003eBeim Crawling ruft ein Bot Seiten ab. Bei der Indexierung werden die abgerufenen Inhalte für die Suche verarbeitet. Google erklärt, dass nicht alle gecrawlten Seiten in den Index aufgenommen werden. \u003ca href=\"https://developers.google.com/crawling/docs/crawl-budget\"\u003eGoogle-Leitfaden zum Crawling-Budget\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003ePrüfpunkt\u003c/th\u003e\n\u003cth\u003eWas zu prüfen ist\u003c/th\u003e\n\u003cth\u003eZu lösendes Problem\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Prüfpunkt\"\u003eInitiales HTML\u003c/td\u003e\n\u003ctd data-label=\"Was zu prüfen ist\"\u003eOb Titel und zentraler Seiteninhalt in der Antwort enthalten sind\u003c/td\u003e\n\u003ctd data-label=\"Zu lösendes Problem\"\u003eAbhängigkeit von zusätzlicher Codeausführung, um den Inhalt zu lesen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Prüfpunkt\"\u003eRendering\u003c/td\u003e\n\u003ctd data-label=\"Was zu prüfen ist\"\u003eOb die Inhalte nach der Ausführung von JavaScript korrekt erscheinen\u003c/td\u003e\n\u003ctd data-label=\"Zu lösendes Problem\"\u003eFehlende Inhalte durch Ausführungsfehler oder Blockierungen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Prüfpunkt\"\u003eTTFB\u003c/td\u003e\n\u003ctd data-label=\"Was zu prüfen ist\"\u003eZeit bis zum Eintreffen der ersten Antwort\u003c/td\u003e\n\u003ctd data-label=\"Zu lösendes Problem\"\u003eVerzögerungen beim Verbindungsaufbau und bei der Serverantwort\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Prüfpunkt\"\u003eHTML-Cache\u003c/td\u003e\n\u003ctd data-label=\"Was zu prüfen ist\"\u003eOb öffentliche Dokumente im CDN wiederverwendet werden\u003c/td\u003e\n\u003ctd data-label=\"Zu lösendes Problem\"\u003eAufwand durch wiederholte Anfragen an den Ursprungsserver\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Prüfpunkt\"\u003eIndexierungsstatus\u003c/td\u003e\n\u003ctd data-label=\"Was zu prüfen ist\"\u003eWie Google die betreffende URL verarbeitet hat\u003c/td\u003e\n\u003ctd data-label=\"Zu lösendes Problem\"\u003eVerwechslung von erfolgreichem Crawling und Aufnahme in den Suchindex\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#warum-react-seiten-als-leeres-html-erscheinen\" class=\"anchor\" id=\"warum-react-seiten-als-leeres-html-erscheinen\"\u003e\u003c/a\u003eWarum React-Seiten als leeres HTML erscheinen\u003c/h2\u003e\n\u003cp\u003eDas initiale HTML einer React-Seite hängt von der Implementierung ab. Wenn der Hauptinhalt im Browser erzeugt wird, spricht man von CSR. Bei diesem Verfahren kann die erste Antwort nur ausführbaren Code und keinen Hauptinhalt enthalten.\u003c/p\u003e\n\u003cp\u003eGoogle führt JavaScript mithilfe von Chromium aus. Nach dem Crawling kann eine Seite auf das Rendering warten. Blockierte Seiten oder Dateien können vom Rendering ausgeschlossen werden. Auch führt nicht jeder Bot JavaScript aus. \u003ca href=\"https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics\"\u003eGoogle-Grundlagen zu JavaScript SEO\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eBeurteilen Sie den Crawling-Status deshalb nicht allein danach, ob die Seite korrekt angezeigt wird. Prüfen Sie zuerst, ob die initiale Antwort den Hauptinhalt enthält. Das von Google gerenderte Ergebnis können Sie mit der URL-Prüfung in der Search Console kontrollieren.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#statische-generierung-und-serverseitiges-rendering-im-vergleich\" class=\"anchor\" id=\"statische-generierung-und-serverseitiges-rendering-im-vergleich\"\u003e\u003c/a\u003eStatische Generierung und serverseitiges Rendering im Vergleich\u003c/h2\u003e\n\u003cp\u003eWie das HTML erzeugt wird, lässt sich danach auswählen, wie der öffentliche Hauptinhalt aktualisiert wird. Bei der statischen Generierung wird HTML vor einer Anfrage erstellt. Beim serverseitigen Rendering erzeugt der Server das HTML, wenn eine Anfrage eingeht. Diese Verfahren lassen sich auch mit React nutzen. \u003ca href=\"https://web.dev/articles/rendering-on-the-web\"\u003eweb.dev-Leitfaden zu Rendering-Verfahren\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eVerfahren\u003c/th\u003e\n\u003cth\u003eZeitpunkt der HTML-Erzeugung\u003c/th\u003e\n\u003cth\u003eGeeignete Einsatzsituationen\u003c/th\u003e\n\u003cth\u003eIm Betrieb zu prüfen\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Verfahren\"\u003eClientseitiges Rendering CSR\u003c/td\u003e\n\u003ctd data-label=\"Zeitpunkt der HTML-Erzeugung\"\u003eWenn JavaScript im Browser ausgeführt wird\u003c/td\u003e\n\u003ctd data-label=\"Geeignete Einsatzsituationen\"\u003eAnsichten mit vielen Nutzerinteraktionen\u003c/td\u003e\n\u003ctd data-label=\"Im Betrieb zu prüfen\"\u003eErforderliche Ausführungen und Anfragen bis zur Anzeige des Hauptinhalts\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Verfahren\"\u003eStatische Generierung SSG\u003c/td\u003e\n\u003ctd data-label=\"Zeitpunkt der HTML-Erzeugung\"\u003eBeim Build oder bei der Erstellung von Inhalten\u003c/td\u003e\n\u003ctd data-label=\"Geeignete Einsatzsituationen\"\u003eÖffentliche Dokumente, die allen Besuchern denselben Inhalt zeigen\u003c/td\u003e\n\u003ctd data-label=\"Im Betrieb zu prüfen\"\u003eNeugenerierung und Bereitstellung nach Änderungen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Verfahren\"\u003eServerseitiges Rendering SSR\u003c/td\u003e\n\u003ctd data-label=\"Zeitpunkt der HTML-Erzeugung\"\u003eBei der Verarbeitung einer Seitenanfrage\u003c/td\u003e\n\u003ctd data-label=\"Geeignete Einsatzsituationen\"\u003eAnsichten, deren aktuelle Inhalte bei jeder Anfrage zusammengestellt werden\u003c/td\u003e\n\u003ctd data-label=\"Im Betrieb zu prüfen\"\u003eZeit für Datenabfragen und HTML-Erzeugung\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Verfahren\"\u003eVorab-Rendering\u003c/td\u003e\n\u003ctd data-label=\"Zeitpunkt der HTML-Erzeugung\"\u003eWenn die App vor der Bereitstellung ausgeführt wird, um HTML zu erzeugen\u003c/td\u003e\n\u003ctd data-label=\"Geeignete Einsatzsituationen\"\u003eWenn der initiale Hauptinhalt einer bestehenden App vorab bereitgestellt werden soll\u003c/td\u003e\n\u003ctd data-label=\"Im Betrieb zu prüfen\"\u003eJavaScript, das für die anschließenden Funktionen benötigt wird\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eStatische Generierung und CDN erfüllen unterschiedliche Aufgaben. Bei der statischen Generierung geht es darum, wann HTML erzeugt wird. Ein CDN dient der Auslieferung und Wiederverwendung von Inhalten. Auch serverseitig erzeugtes HTML kann unter passenden Bedingungen im CDN gecacht werden.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#was-bedeutet-eine-ttfb-von-08-sekunden\" class=\"anchor\" id=\"was-bedeutet-eine-ttfb-von-08-sekunden\"\u003e\u003c/a\u003eWas bedeutet eine TTFB von 0.8 Sekunden?\u003c/h2\u003e\n\u003cp\u003eTTFB ist die Zeit vom Beginn der Navigation bis zum ersten Byte der Antwort. web.dev nennt für die meisten Websites \u003cstrong\u003ehöchstens 0.8 Sekunden\u003c/strong\u003e als groben Zielwert. Das ist nicht die Zeit bis zur vollständigen Anzeige der Seite. TTFB selbst gehört auch nicht zu den Core Web Vitals. \u003ca href=\"https://web.dev/articles/ttfb\"\u003eweb.dev-Erklärung zu TTFB\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eTTFB umfasst auch Verzögerungen außerhalb der internen Serververarbeitung. Bei der DNS-Abfrage wird die Verbindungsadresse einer Domain ermittelt. Auch der Aufbau von TCP- und TLS-Verbindungen kann Zeit benötigen. Weiterleitungen an eine andere Adresse wirken sich ebenfalls aus.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eZeit für DNS-Abfrage und Verbindungsvorbereitung\u003c/li\u003e\n\u003cli\u003eÜbertragungszeit von Anfrage und Antwort über das Netzwerk\u003c/li\u003e\n\u003cli\u003eZeit für Datenabfragen und HTML-Erzeugung auf dem Ursprungsserver\u003c/li\u003e\n\u003cli\u003eZeit für Weiterleitungen vor der ersten Antwort\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAllein aus dem Standort eines Servers in Seoul lässt sich nicht schließen, dass die TTFB mehr als 0.8 Sekunden beträgt. Das Ergebnis hängt vom Zugriffsort und davon ab, ob Verbindungen wiederverwendet werden. Die Crawler von Google verwenden hauptsächlich IP-Adressen aus den USA. Sie können jedoch auch über IP-Adressen aus anderen Ländern zugreifen. \u003ca href=\"https://developers.google.com/crawling/docs/crawlers-fetchers/overview-google-crawlers?hl=en\"\u003eTechnische Eigenschaften der Google-Crawler\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eAnhaltende Antwortverzögerungen beeinflussen die Crawling-Kapazität von Google. Auch Serverfehler können zu einem geringeren Crawling-Umfang führen. Es gibt jedoch keine Regel, nach der das Crawling unterbrochen wird, sobald 0.8 Sekunden einmal überschritten werden. Auch die Seitenqualität und die Aktualisierungshäufigkeit beeinflussen den Crawling-Bedarf. \u003ca href=\"https://developers.google.com/crawling/docs/crawl-budget\"\u003eGoogle-Leitfaden zum Crawling-Budget\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#warum-der-html-cache-im-cdn-gepr%C3%BCft-werden-muss\" class=\"anchor\" id=\"warum-der-html-cache-im-cdn-geprüft-werden-muss\"\u003e\u003c/a\u003eWarum der HTML-Cache im CDN geprüft werden muss\u003c/h2\u003e\n\u003cp\u003eDas Cloudflare CDN speichert HTML standardmäßig nicht im Cache. Auch wenn Bilder oder CSS gecacht werden, muss das Dokument mit dem Hauptinhalt gesondert geprüft werden. Das Standardverhalten anderer CDNs finden Sie in der Dokumentation des jeweiligen Dienstes.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eDas Cloudflare CDN speichert HTML oder JSON standardmäßig nicht im Cache.\u003c/p\u003e\n\u003cp\u003eCloudflare, Standardverhalten des Caches\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eDieser Satz bedeutet, dass HTML und JSON standardmäßig nicht zum Caching vorgesehen sind. Öffentliches HTML kann über Cache Rules für das Caching freigegeben werden. Ob es tatsächlich gespeichert wird, hängt auch von Bedingungen wie Antwort-Headern und Cookies ab. \u003ca href=\"https://developers.cloudflare.com/cache/concepts/default-cache-behavior/\"\u003eCloudflare-Standardverhalten des Caches\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eEin Cache ermöglicht es, gespeicherte Antworten wiederzuverwenden. Die Anbindung an ein CDN bedeutet nicht, dass alle Dokumente sofort weltweit repliziert werden. Cloudflare speichert Inhalte in dem Rechenzentrum im Cache, das die Anfrage verarbeitet. Bei Anfragen nach Inhalten, die nicht im Cache liegen, kann ein Abruf vom Ursprungsserver erforderlich sein. \u003ca href=\"https://developers.cloudflare.com/cache/get-started/\"\u003eCloudflare-Einstieg in das Caching\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eSchließen Sie personalisierte Seiten aus, wenn Sie Cache-Regeln auf öffentliches HTML anwenden. Cloudflare warnt davor, dass durch das Caching von dynamischem HTML Informationen anderer Personen ausgeliefert werden können. Speichern Sie Login- oder Kontoseiten nicht im Cache. \u003ca href=\"https://developers.cloudflare.com/cache/how-to/cache-rules/examples/cache-everything/\"\u003eCloudflare-Hinweise zu Cache Everything\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#kriterien-f%C3%BCr-das-caching-je-nach-seitentyp\" class=\"anchor\" id=\"kriterien-für-das-caching-je-nach-seitentyp\"\u003e\u003c/a\u003eKriterien für das Caching je nach Seitentyp\u003c/h2\u003e\n\u003cp\u003eAusgangspunkt für den Umfang des Cachings ist die Frage, ob Besucher denselben Inhalt sehen. Öffentliche Beschreibungstexte eignen sich gut für eine gemeinsame Wiederverwendung. Antworten, deren Inhalt sich je nach Anmeldestatus unterscheidet, müssen gesondert behandelt werden.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eSeiteneigenschaft\u003c/th\u003e\n\u003cth\u003eZu prüfende Konfiguration\u003c/th\u003e\n\u003cth\u003eZusätzlich zu prüfen\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Seiteneigenschaft\"\u003eDerselbe Beschreibungstext für alle Besucher\u003c/td\u003e\n\u003ctd data-label=\"Zu prüfende Konfiguration\"\u003eStatische Generierung und Caching von öffentlichem HTML\u003c/td\u003e\n\u003ctd data-label=\"Zusätzlich zu prüfen\"\u003eNeugenerierung und Cache-Aktualisierung nach Änderungen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Seiteneigenschaft\"\u003eÖffentlicher Hauptinhalt mit häufig wechselnden Zahlenwerten\u003c/td\u003e\n\u003ctd data-label=\"Zu prüfende Konfiguration\"\u003eAktualisierung von Hauptinhalt und veränderlichen Daten getrennt behandeln\u003c/td\u003e\n\u003ctd data-label=\"Zusätzlich zu prüfen\"\u003eBezugszeitpunkt der Werte und Anzeige bei Fehlern\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Seiteneigenschaft\"\u003eAktuelle öffentliche Informationen zum Anfragezeitpunkt erforderlich\u003c/td\u003e\n\u003ctd data-label=\"Zu prüfende Konfiguration\"\u003eServerseitiges Rendering und bedingtes Caching prüfen\u003c/td\u003e\n\u003ctd data-label=\"Zusätzlich zu prüfen\"\u003eZulässige Verzögerung der Informationen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Seiteneigenschaft\"\u003eLogin-, Konto- und Zahlungsseiten\u003c/td\u003e\n\u003ctd data-label=\"Zu prüfende Konfiguration\"\u003eVom gemeinsamen HTML-Cache ausschließen\u003c/td\u003e\n\u003ctd data-label=\"Zusätzlich zu prüfen\"\u003eAuthentifizierungs-Cookies und nutzerspezifische Antworten\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Seiteneigenschaft\"\u003eÖffentliche Dokumente in mehreren Sprachen\u003c/td\u003e\n\u003ctd data-label=\"Zu prüfende Konfiguration\"\u003eSprachspezifische URLs und Cache jedes Dokuments\u003c/td\u003e\n\u003ctd data-label=\"Zusätzlich zu prüfen\"\u003eVerknüpfung der Übersetzungen und sprachspezifische Aktualisierung\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eWenn Echtzeitdaten später geladen werden, lässt sich ein statischer Hauptinhalt leichter beibehalten. Verschieben Sie jedoch nicht sämtliche für die Suche wesentlichen Inhalte auf einen späteren Ladezeitpunkt. Das kann dem Zweck widersprechen, initiales HTML bereitzustellen.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#h%C3%A4ufige-fehler-und-pr%C3%BCfkriterien\" class=\"anchor\" id=\"häufige-fehler-und-prüfkriterien\"\u003e\u003c/a\u003eHäufige Fehler und Prüfkriterien\u003c/h2\u003e\n\u003cp\u003eWer Ergebnisse nur anhand von Technologienamen oder Einstellungsseiten beurteilt, übersieht leicht Fehler. Prüfen Sie das tatsächliche HTML zusammen mit den Antwort-Headern. Die folgenden Zustände müssen voneinander unterschieden werden.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eHäufige Annahme\u003c/th\u003e\n\u003cth\u003eZu prüfendes Kriterium\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Häufige Annahme\"\u003eSuchbots können React-Websites nicht lesen\u003c/td\u003e\n\u003ctd data-label=\"Zu prüfendes Kriterium\"\u003eInitiales HTML und das Rendering-Ergebnis von Google\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Häufige Annahme\"\u003eBei einer TTFB von 0.8 Sekunden ist auch die gesamte Seite sichtbar\u003c/td\u003e\n\u003ctd data-label=\"Zu prüfendes Kriterium\"\u003eZeit von der ersten Antwort bis zur Anzeige des Hauptinhalts\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Häufige Annahme\"\u003eDas CDN ist angebunden, also wird auch HTML gecacht\u003c/td\u003e\n\u003ctd data-label=\"Zu prüfendes Kriterium\"\u003eCache-Status der HTML-Anfrage\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Häufige Annahme\"\u003eEine statische Datei enthält immer die neuesten Inhalte\u003c/td\u003e\n\u003ctd data-label=\"Zu prüfendes Kriterium\"\u003eLetzter Erstellungszeitpunkt und bereitgestellter Inhalt\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Häufige Annahme\"\u003eEine schnelle Antwort bedeutet, dass auch die Aufnahme in den Suchindex abgeschlossen ist\u003c/td\u003e\n\u003ctd data-label=\"Zu prüfendes Kriterium\"\u003eIndexierungsstatus in der Search Console\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Häufige Annahme\"\u003eEin einzelner Cache-Treffer reicht aus, um die weltweite Geschwindigkeit zu beurteilen\u003c/td\u003e\n\u003ctd data-label=\"Zu prüfendes Kriterium\"\u003eMessergebnisse nach Zugriffsregion und Cache-Trefferstatus\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e\u003ccode\u003eCF-Cache-Status\u003c/code\u003e von Cloudflare ist ein Header, der den Cache-Status anzeigt. \u003ccode\u003eHIT\u003c/code\u003e bedeutet, dass die Antwort im Cache gefunden wurde. \u003ccode\u003eMISS\u003c/code\u003e bedeutet, dass sie zum Zeitpunkt der Anfrage nicht im Cache lag und vom Ursprungsserver abgerufen wurde. \u003ccode\u003eDYNAMIC\u003c/code\u003e bezeichnet einen Zustand, in dem die Antwort nicht als cachefähig behandelt wurde. \u003ca href=\"https://developers.cloudflare.com/cache/concepts/cache-responses/\"\u003eCloudflare-Erklärung zu Cache-Antworten\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#cache-aktualisierung-nach-inhalts%C3%A4nderungen\" class=\"anchor\" id=\"cache-aktualisierung-nach-inhaltsänderungen\"\u003e\u003c/a\u003eCache-Aktualisierung nach Inhaltsänderungen\u003c/h2\u003e\n\u003cp\u003eBei statischen Dateien und CDN-Caches muss auch der Ablauf zur Übernahme von Änderungen geplant werden. Selbst wenn das Original geändert wurde, werden alte Inhalte ausgeliefert, solange der bisherige Cache bestehen bleibt. Wenn HTML und JSON gemeinsam veröffentlicht werden, müssen auch die Inhalte beider Formate übereinstimmen.\u003c/p\u003e\n\u003cp\u003eDie folgende Prüfreihenfolge gilt, wenn Dokumente und Datendateien gemeinsam betrieben werden.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eLegen Sie die Änderungen in den Quelldaten fest.\u003c/li\u003e\n\u003cli\u003eGenerieren Sie HTML und Datendateien aus demselben Änderungsstand neu.\u003c/li\u003e\n\u003cli\u003eStellen Sie die neuen Dateien bereit und aktualisieren Sie anschließend den Cache der geänderten URLs.\u003c/li\u003e\n\u003cli\u003eRufen Sie jede URL erneut ab und prüfen Sie, ob die geänderten Inhalte übereinstimmen.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eCloudflare empfiehlt, den Cache für einzelne URLs zu löschen. Beim Löschen des Caches werden gespeicherte Antworten entfernt. Statisches HTML muss separat neu erzeugt werden. Verbinden Sie deshalb die Dateierzeugung und die Cache-Aktualisierung im selben Bereitstellungsablauf. \u003ca href=\"https://developers.cloudflare.com/cache/how-to/purge-cache/\"\u003eCloudflare-Leitfaden zum Löschen des Caches\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eLegen Sie die Aktualisierungsintervalle danach fest, welche Verzögerung die Inhalte zulassen. Für Beschreibungstexte und Echtzeitwerte muss nicht derselbe Rhythmus gelten. Eine kurze Cache-Gültigkeitsdauer allein löst nicht alle Aktualisierungsprobleme.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#hreflang-kriterien-f%C3%BCr-mehrsprachige-websites\" class=\"anchor\" id=\"hreflang-kriterien-für-mehrsprachige-websites\"\u003e\u003c/a\u003ehreflang-Kriterien für mehrsprachige Websites\u003c/h2\u003e\n\u003cp\u003e\u003ccode\u003ehreflang\u003c/code\u003e verknüpft die sprach- und regionsspezifischen Adressen desselben Inhalts. Es erstellt keine Übersetzungen. Es hilft Google, die passende Sprachversion für Besucher zu finden.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eImplementierungsort\u003c/th\u003e\n\u003cth\u003eArt der Angabe\u003c/th\u003e\n\u003cth\u003eBei der Auswahl zu prüfen\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Implementierungsort\"\u003eHTML\u003c/td\u003e\n\u003ctd data-label=\"Art der Angabe\"\u003eLinks zu alternativen Sprachversionen im \u003ccode\u003ehead\u003c/code\u003e des Dokuments angeben\u003c/td\u003e\n\u003ctd data-label=\"Bei der Auswahl zu prüfen\"\u003eOb die Verwaltung in den jeweiligen Seitenvorlagen möglich ist\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Implementierungsort\"\u003eHTTP-Header\u003c/td\u003e\n\u003ctd data-label=\"Art der Angabe\"\u003eAngabe im \u003ccode\u003eLink\u003c/code\u003e-Header der Antwort\u003c/td\u003e\n\u003ctd data-label=\"Bei der Auswahl zu prüfen\"\u003eOb die Header auf dem Server verwaltet werden können\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Implementierungsort\"\u003eSitemap\u003c/td\u003e\n\u003ctd data-label=\"Art der Angabe\"\u003eBeziehungen zwischen sprachspezifischen URLs in der Sitemap angeben\u003c/td\u003e\n\u003ctd data-label=\"Bei der Auswahl zu prüfen\"\u003eOb die Dokumentliste zentral verwaltet werden kann\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eGoogle behandelt diese Verfahren gleichwertig. Die Angaben müssen daher nicht ausschließlich im HTML stehen. Jedes Sprachdokument muss auf sich selbst und auf die alternativen Sprachversionen verweisen. Prüfen Sie auch die Verknüpfungen zwischen den einander entsprechenden Seiten. \u003ca href=\"https://developers.google.com/search/docs/specialty/international/localized-versions\"\u003eGoogle-Leitfaden zu mehrsprachigen Seiten\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#reihenfolge-zur-pr%C3%BCfung-nach-der-bereitstellung\" class=\"anchor\" id=\"reihenfolge-zur-prüfung-nach-der-bereitstellung\"\u003e\u003c/a\u003eReihenfolge zur Prüfung nach der Bereitstellung\u003c/h2\u003e\n\u003cp\u003ePrüfen Sie nach der Bereitstellung die Auslieferung des Hauptinhalts und das Cache-Verhalten getrennt. Halten Sie bei Geschwindigkeitsmessungen auch die Messregion und den Cache-Status fest. Mit der folgenden Prüfreihenfolge lassen sich Problemstellen leichter eingrenzen.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003ePrüfen Sie die Antwort des HTML-Dokuments in den Entwicklertools des Browsers. Sehen Sie nach, ob der zentrale Seiteninhalt in der Antwort enthalten ist.\u003c/li\u003e\n\u003cli\u003ePrüfen Sie das gerenderte HTML mit der URL-Prüfung in der Search Console. Kontrollieren Sie den tatsächlichen Indexierungsstatus zusätzlich separat.\u003c/li\u003e\n\u003cli\u003ePrüfen Sie die Cache-Header der HTML-Antwort. Lesen Sie bei Cloudflare den Wert von \u003ccode\u003eCF-Cache-Status\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eMessen Sie dasselbe Dokument aus den wichtigsten Zugriffsregionen. Unterscheiden Sie zwischen Anfragen ohne Cache-Treffer und solchen mit Cache-Treffer.\u003c/li\u003e\n\u003cli\u003ePrüfen Sie nach einer Inhaltsänderung, ob die Aktualisierung übernommen wurde. Kontrollieren Sie auch, ob Login-Seiten vom Cache ausgeschlossen sind.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eCloudflare warnt davor, dass zu weitreichendes Caching von dynamischem HTML die Anmeldung beeinträchtigen kann. Speichern Sie Login-Formulare und Seiten für authentifizierte Nutzer nicht im Cache. Prüfen Sie nach Änderungen auch, ob die Authentifizierungs-Cookies erhalten bleiben. \u003ca href=\"https://developers.cloudflare.com/cache/troubleshooting/dynamic-content-and-login-issues/\"\u003eCloudflare-Leitfaden zu Anmeldeproblemen\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#implementierungsvorgaben-f%C3%BCr-die-programmierung-mit-ki\" class=\"anchor\" id=\"implementierungsvorgaben-für-die-programmierung-mit-ki\"\u003e\u003c/a\u003eImplementierungsvorgaben für die Programmierung mit KI\u003c/h2\u003e\n\u003cp\u003eFordern Sie von der KI neben bestimmten Technologien auch überprüfbare Ergebnisse an. Hilfreich ist es, die Inhalte des initialen HTML und den Umfang der Cache-Ausschlüsse ausdrücklich festzulegen. Der folgende Text ist eine Beispielanfrage für die Erstellung öffentlicher Wissensseiten.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eNehmen Sie den zentralen Inhalt öffentlicher Wissensseiten in das initiale HTML auf.\n\u003c/span\u003e\u003cspan\u003ePrüfen Sie für öffentliche Dokumente vorrangig die statische Generierung.\n\u003c/span\u003e\u003cspan\u003eErläutern Sie die Aktualisierung veränderlicher Daten gesondert.\n\u003c/span\u003e\u003cspan\u003ePrüfen Sie, ob das CDN HTML im Cache speichert.\n\u003c/span\u003e\u003cspan\u003eSchließen Sie Login-, Konto- und Zahlungsseiten vom gemeinsamen Cache aus.\n\u003c/span\u003e\u003cspan\u003eVerknüpfen Sie bei Inhaltsänderungen die Neugenerierung statischer Dateien mit der Cache-Aktualisierung.\n\u003c/span\u003e\u003cspan\u003eRichten Sie bei mehrsprachigen Seiten hreflang-Verknüpfungen ein.\n\u003c/span\u003e\u003cspan\u003eGeben Sie an, wie das initiale HTML, der Cache-Status und die Übernahme von Änderungen geprüft werden können.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n","tags":["KI Entwicklung","Content Monetarisierung","Technologiestrategie","Entwicklungstools"],"faqs":[{"question":"Müssen Low-Involvement-Websites mit einem bestimmten Framework erstellt werden?","answer":"Ein bestimmtes Framework ist nicht zwingend erforderlich. Prüfen Sie, ob der Hauptinhalt im initialen HTML enthalten ist. Auch das Caching und die Aktualisierung öffentlicher Inhalte sollten Sie prüfen."},{"question":"Führt Google kein JavaScript aus?","answer":"Google führt JavaScript mit Chromium aus. Allerdings können Wartezeiten beim Rendern und blockierte Ressourcen die Verarbeitung beeinflussen. Wenn der Hauptinhalt im initialen HTML enthalten ist, lässt sich die Abhängigkeit von zusätzlicher Codeausführung verringern."},{"question":"Lassen sich auch mit React erstellte Websites statisch generieren?","answer":"Auch mit React lässt sich statisches HTML generieren. Die Erstellung von HTML auf dem Server wird ebenfalls unterstützt. Allein daran, ob React verwendet wird, lässt sich der Inhalt des initialen HTML nicht beurteilen."},{"question":"Ist die Seite bei einer TTFB von höchstens 0.8 Sekunden vollständig geladen?","answer":"TTFB bezeichnet die Zeit, bis das erste Byte der Antwort eintrifft. Das Herunterladen von Bildern und der Seitenaufbau können danach noch weitergehen. Dieser Wert muss von der gesamten Ladezeit der Seite unterschieden werden."},{"question":"Wird eine Seite bei einer TTFB von mehr als 0.8 Sekunden aus der Google-Suche ausgeschlossen?","answer":"0.8 Sekunden sind ein grober Leistungszielwert, den web.dev vorgibt. Es gibt keine Regel, nach der eine Überschreitung zum Ausschluss aus der Suche führt. Anhaltende Antwortverzögerungen und Serverfehler können die Crawling-Kapazität beeinflussen."},{"question":"Ist ein Server in Korea für eine globale Website nachteilig?","answer":"Bei weit entfernten Besuchern können Netzwerklatenzen auftreten. Aus dem Standort allein lässt sich jedoch keine bestimmte Antwortzeit ableiten. Beurteilen Sie dies anhand tatsächlicher Messwerte aus den wichtigsten Zugriffsregionen."},{"question":"Wird nach der Einbindung von Cloudflare auch HTML automatisch gecacht?","answer":"Das Cloudflare CDN cacht standardmäßig weder HTML noch JSON. Prüfen Sie die Cache Rules, die auf öffentliches HTML angewendet werden sollen. Nach der Anwendung der Regeln müssen Sie den tatsächlichen Cache-Status anhand der Antwort-Header überprüfen."},{"question":"Ist auch die erste Anfrage, die nicht im CDN-Cache liegt, immer schnell?","answer":"Bei Anfragen, die nicht im Cache liegen, muss die Antwort möglicherweise vom Ursprungsserver abgerufen werden. Daher kann sich die Latenz von der bei einem Cache-Treffer unterscheiden. Messen Sie beide Zustände getrennt."},{"question":"Darf HTML-Caching auch auf Login-Seiten angewendet werden?","answer":"Cachen Sie weder Login-Seiten noch HTML-Inhalte, die eine Authentifizierung erfordern. Cloudflare warnt davor, dass übermäßiges Caching die Login-Funktion beeinträchtigen kann. Außerdem besteht das Risiko, dass nutzerspezifische Informationen an andere Besucher weitergegeben werden."},{"question":"Was kann ich tun, wenn nach der Bearbeitung eines Beitrags auf einer statischen Website noch der alte Inhalt angezeigt wird?","answer":"Prüfen Sie zunächst, ob das neue HTML generiert und bereitgestellt wurde. Aktualisieren Sie anschließend den CDN-Cache für die geänderte URL. Durch das bloße Löschen des Caches werden statische Dateien nicht neu generiert."},{"question":"Muss hreflang ausschließlich im HTML angegeben werden?","answer":"Google unterstützt die Angabe über HTML, HTTP-Header und Sitemaps. Aus Sicht von Google sind die drei Methoden gleichwertig. Wählen Sie die Methode, die sich für Sie gut verwalten lässt, und halten Sie die Verknüpfungen zwischen den Sprachversionen konsistent."},{"question":"Muss das Crawling-Budget auch bei einer kleinen Website intensiv verwaltet werden?","answer":"Googles Hinweise zum Crawling-Budget richten sich hauptsächlich an große, häufig aktualisierte Websites. Wenn Ihre Website nur wenige Seiten hat, beginnen Sie mit der Aktualisierung der Sitemap und der Prüfung der Indexierungsberichte. Falls Serverfehler auftreten oder Hauptinhalte fehlen, beheben Sie zuerst diese Probleme."}],"sources":[{"url":"https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics","title":"Google Search Central: Die Grundlagen von JavaScript-SEO verstehen","type":"source"},{"url":"https://web.dev/articles/rendering-on-the-web","title":"web.dev: Rendering im Web","type":"source"},{"url":"https://web.dev/articles/ttfb","title":"web.dev: Time to First Byte (TTFB), aktualisiert am 18. November 2025","type":"data_point"},{"url":"https://developers.google.com/crawling/docs/crawlers-fetchers/overview-google-crawlers?hl=en","title":"Google: Überblick über die Crawler und Fetcher von Google","type":"source"},{"url":"https://developers.google.com/crawling/docs/crawl-budget","title":"Google: Ihr Crawling-Budget optimieren","type":"source"},{"url":"https://developers.cloudflare.com/cache/concepts/default-cache-behavior/","title":"Cloudflare: Standardverhalten des Caches","type":"source"},{"url":"https://developers.cloudflare.com/cache/get-started/","title":"Cloudflare Cache: Erste Schritte","type":"source"},{"url":"https://developers.cloudflare.com/cache/how-to/cache-rules/examples/cache-everything/","title":"Cloudflare: Cache-Stufe (Cache Everything)","type":"source"},{"url":"https://developers.cloudflare.com/cache/concepts/cache-responses/","title":"Antworten des Cloudflare-Caches","type":"source"},{"url":"https://developers.cloudflare.com/cache/how-to/purge-cache/","title":"Cloudflare: Cache leeren","type":"source"},{"url":"https://developers.cloudflare.com/cache/troubleshooting/dynamic-content-and-login-issues/","title":"Cloudflare: Probleme mit dynamischen Inhalten und der Anmeldung","type":"source"},{"url":"https://developers.google.com/search/docs/specialty/international/localized-versions","title":"Google Search Central: Google über lokalisierte Versionen Ihrer Seite informieren","type":"source"}],"images":[{"id":2451,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzgxNjYsInB1ciI6ImJsb2JfaWQifX0=--3301cc345476b9a82de57f9e5bdbad57a8717225/ai-cace8faa.webp","is_representative":true,"generation_method":"ai_photo","license":"ai_generated","mime_type":"image/webp","width":1536,"height":1024,"translations":{"ko":{"alt":"보라색 케이블이 정돈된 서버 랙 옆에서 장비 상태를 살펴보는 남성","caption":"공개 페이지의 HTML 캐시는 적용 범위와 콘텐츠 수정 후 갱신 정책을 함께 설계해야 합니다.","description":null},"en":{"alt":"A man inspecting a server rack with neatly bundled purple cables","caption":"HTML caching for public pages requires defining both its scope and how it is refreshed after content changes.","description":null},"ja":{"alt":"紫色のケーブルが整然と束ねられたサーバーラックの横で機器を確認する男性","caption":"公開ページのHTMLキャッシュは、適用範囲とコンテンツ変更後の更新方針を併せて設計する必要があります。","description":null},"es":{"alt":"Un hombre revisa un rack de servidores con cables morados ordenados en haces","caption":"La caché HTML de las páginas públicas requiere definir su alcance y cómo se actualizará tras modificar el contenido.","description":null},"id":{"alt":"Seorang pria memeriksa rak server dengan kabel ungu yang tertata rapi","caption":"Cache HTML untuk halaman publik memerlukan penetapan cakupan dan kebijakan pembaruan setelah konten diubah.","description":null},"pt":{"alt":"Um homem inspeciona um rack de servidores com cabos roxos organizados em feixes","caption":"O cache HTML de páginas públicas exige definir seu escopo e como será atualizado após alterações no conteúdo.","description":null},"zh-hant":{"alt":"一名男子在伺服器機架旁檢查設備，機架內的紫色線纜整齊成束","caption":"公開頁面的 HTML 快取需要同時規劃適用範圍與內容修改後的更新政策。","description":null},"de":{"alt":"Ein Mann prüft ein Serverrack mit ordentlich gebündelten violetten Kabeln","caption":"Für den HTML-Cache öffentlicher Seiten müssen der Geltungsbereich und die Aktualisierung nach Inhaltsänderungen festgelegt werden.","description":null}}},{"id":2452,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzgxNzIsInB1ciI6ImJsb2JfaWQifX0=--6d794cafac94909fa4ac95705b51dc5bde79c2df/ai-9e2e0147.webp","is_representative":false,"generation_method":"ai_semi","license":"ai_generated","mime_type":"image/webp","width":1536,"height":1024,"translations":{"ko":{"alt":"두 태블릿의 웹페이지를 비교하는 여성과 문서 갱신이 두 브라우저로 이어지는 도식","caption":"콘텐츠 수정 후에는 재생성한 HTML이 캐시에도 반영됐는지 확인해야 합니다.","description":null},"en":{"alt":"A woman compares web pages on two tablets beside a diagram linking a document refresh to two browser windows.","caption":"After content changes, verify that the cache also reflects the regenerated HTML.","description":null},"ja":{"alt":"2台のタブレットでウェブページを比較する女性と、文書の更新から2つのブラウザーへつながる図","caption":"コンテンツの修正後は、再生成したHTMLがキャッシュにも反映されているか確認する必要があります。","description":null},"es":{"alt":"Una mujer compara páginas web en dos tabletas junto a un diagrama de actualización de un documento.","caption":"Tras modificar el contenido, hay que comprobar que la caché también refleje el HTML regenerado.","description":null},"id":{"alt":"Seorang perempuan membandingkan halaman web di dua tablet di samping diagram pembaruan dokumen.","caption":"Setelah konten diubah, pastikan cache juga mencerminkan HTML yang dibuat ulang.","description":null},"pt":{"alt":"Uma mulher compara páginas web em dois tablets ao lado de um diagrama de atualização de um documento.","caption":"Após alterar o conteúdo, é preciso verificar se o cache também reflete o HTML regenerado.","description":null},"zh-hant":{"alt":"一名女性比較兩台平板上的網頁，旁邊的圖示呈現文件更新後連向兩個瀏覽器視窗","caption":"修改內容後，應確認快取也已反映重新產生的 HTML。","description":null},"de":{"alt":"Eine Frau vergleicht Webseiten auf zwei Tablets neben einem Diagramm zur Dokumentaktualisierung.","caption":"Nach Inhaltsänderungen muss geprüft werden, ob auch der Cache das neu generierte HTML enthält.","description":null}}}],"published_at":"2026-11-05T07:45:55+09:00","updated_at":"2026-11-05T07:45:55+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/en/articles/low-involvement-web-static-generation-html-cache"}