---
title: "Low-Involvement-Web: Statische Generierung und HTML-Cache"
locale: de
category: knowledge_base
category_name: "Wissensdatenbank"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/low-involvement-web-static-generation-html-cache
published_at: 2026-11-05T07:45:55+09:00
---

# Low-Involvement-Web: Statische Generierung und HTML-Cache

> 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.

## 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.

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.

Die Angabe zur TTFB basiert auf der am 18. November 2025 aktualisierten Dokumentation von web.dev.

## Technische Voraussetzungen, die bei Websites mit geringem Involvement zuerst zu prüfen sind

In 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.

Beim 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)

| Prüfpunkt | Was zu prüfen ist | Zu lösendes Problem |
| --- | --- | --- |
| Initiales HTML | Ob Titel und zentraler Seiteninhalt in der Antwort enthalten sind | Abhängigkeit von zusätzlicher Codeausführung, um den Inhalt zu lesen |
| Rendering | Ob die Inhalte nach der Ausführung von JavaScript korrekt erscheinen | Fehlende Inhalte durch Ausführungsfehler oder Blockierungen |
| TTFB | Zeit bis zum Eintreffen der ersten Antwort | Verzögerungen beim Verbindungsaufbau und bei der Serverantwort |
| HTML-Cache | Ob öffentliche Dokumente im CDN wiederverwendet werden | Aufwand durch wiederholte Anfragen an den Ursprungsserver |
| Indexierungsstatus | Wie Google die betreffende URL verarbeitet hat | Verwechslung von erfolgreichem Crawling und Aufnahme in den Suchindex |

## Warum React-Seiten als leeres HTML erscheinen

Das 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.

Google 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)

Beurteilen 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.

## Statische Generierung und serverseitiges Rendering im Vergleich

Wie 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)

| Verfahren | Zeitpunkt der HTML-Erzeugung | Geeignete Einsatzsituationen | Im Betrieb zu prüfen |
| --- | --- | --- | --- |
| Clientseitiges Rendering CSR | Wenn JavaScript im Browser ausgeführt wird | Ansichten mit vielen Nutzerinteraktionen | Erforderliche Ausführungen und Anfragen bis zur Anzeige des Hauptinhalts |
| Statische Generierung SSG | Beim Build oder bei der Erstellung von Inhalten | Öffentliche Dokumente, die allen Besuchern denselben Inhalt zeigen | Neugenerierung und Bereitstellung nach Änderungen |
| Serverseitiges Rendering SSR | Bei der Verarbeitung einer Seitenanfrage | Ansichten, deren aktuelle Inhalte bei jeder Anfrage zusammengestellt werden | Zeit für Datenabfragen und HTML-Erzeugung |
| 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 |

Statische 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.

## Was bedeutet eine TTFB von 0.8 Sekunden?

TTFB 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)

TTFB 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.

- Zeit für DNS-Abfrage und Verbindungsvorbereitung
- Übertragungszeit von Anfrage und Antwort über das Netzwerk
- Zeit für Datenabfragen und HTML-Erzeugung auf dem Ursprungsserver
- Zeit für Weiterleitungen vor der ersten Antwort

Allein 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)

Anhaltende 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)

## Warum der HTML-Cache im CDN geprüft werden muss

Das 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.

> Das Cloudflare CDN speichert HTML oder JSON standardmäßig nicht im Cache.
>
> Cloudflare, Standardverhalten des Caches

Dieser 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/)

Ein 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/)

Schließ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/)

## Kriterien für das Caching je nach Seitentyp

Ausgangspunkt 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.

| Seiteneigenschaft | Zu prüfende Konfiguration | Zusätzlich zu prüfen |
| --- | --- | --- |
| Derselbe Beschreibungstext für alle Besucher | Statische Generierung und Caching von öffentlichem HTML | Neugenerierung und Cache-Aktualisierung nach Änderungen |
| Öffentlicher Hauptinhalt mit häufig wechselnden Zahlenwerten | Aktualisierung von Hauptinhalt und veränderlichen Daten getrennt behandeln | Bezugszeitpunkt der Werte und Anzeige bei Fehlern |
| Aktuelle öffentliche Informationen zum Anfragezeitpunkt erforderlich | Serverseitiges Rendering und bedingtes Caching prüfen | Zulässige Verzögerung der Informationen |
| Login-, Konto- und Zahlungsseiten | Vom gemeinsamen HTML-Cache ausschließen | Authentifizierungs-Cookies und nutzerspezifische Antworten |
| Öffentliche Dokumente in mehreren Sprachen | Sprachspezifische URLs und Cache jedes Dokuments | Verknüpfung der Übersetzungen und sprachspezifische Aktualisierung |

Wenn 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.

## Häufige Fehler und Prüfkriterien

Wer 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.

| Häufige Annahme | Zu prüfendes Kriterium |
| --- | --- |
| Suchbots können React-Websites nicht lesen | Initiales HTML und das Rendering-Ergebnis von Google |
| Bei einer TTFB von 0.8 Sekunden ist auch die gesamte Seite sichtbar | Zeit von der ersten Antwort bis zur Anzeige des Hauptinhalts |
| Das CDN ist angebunden, also wird auch HTML gecacht | Cache-Status der HTML-Anfrage |
| Eine statische Datei enthält immer die neuesten Inhalte | Letzter Erstellungszeitpunkt und bereitgestellter Inhalt |
| Eine schnelle Antwort bedeutet, dass auch die Aufnahme in den Suchindex abgeschlossen ist | Indexierungsstatus in der Search Console |
| Ein einzelner Cache-Treffer reicht aus, um die weltweite Geschwindigkeit zu beurteilen | Messergebnisse nach Zugriffsregion und Cache-Trefferstatus |

`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/)

## Cache-Aktualisierung nach Inhaltsänderungen

Bei 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.

Die folgende Prüfreihenfolge gilt, wenn Dokumente und Datendateien gemeinsam betrieben werden.

1. Legen Sie die Änderungen in den Quelldaten fest.
2. Generieren Sie HTML und Datendateien aus demselben Änderungsstand neu.
3. Stellen Sie die neuen Dateien bereit und aktualisieren Sie anschließend den Cache der geänderten URLs.
4. Rufen Sie jede URL erneut ab und prüfen Sie, ob die geänderten Inhalte übereinstimmen.

Cloudflare 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/)

Legen 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.

## hreflang-Kriterien für mehrsprachige Websites

`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.

| Implementierungsort | Art der Angabe | Bei der Auswahl zu prüfen |
| --- | --- | --- |
| HTML | Links zu alternativen Sprachversionen im `head` des Dokuments angeben | Ob die Verwaltung in den jeweiligen Seitenvorlagen möglich ist |
| HTTP-Header | Angabe im `Link`-Header der Antwort | Ob die Header auf dem Server verwaltet werden können |
| Sitemap | Beziehungen zwischen sprachspezifischen URLs in der Sitemap angeben | Ob die Dokumentliste zentral verwaltet werden kann |

Google 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)

## Reihenfolge zur Prüfung nach der Bereitstellung

Prü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.

1. 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.
2. Prüfen Sie das gerenderte HTML mit der URL-Prüfung in der Search Console. Kontrollieren Sie den tatsächlichen Indexierungsstatus zusätzlich separat.
3. Prüfen Sie die Cache-Header der HTML-Antwort. Lesen Sie bei Cloudflare den Wert von `CF-Cache-Status`.
4. Messen Sie dasselbe Dokument aus den wichtigsten Zugriffsregionen. Unterscheiden Sie zwischen Anfragen ohne Cache-Treffer und solchen mit Cache-Treffer.
5. Prüfen Sie nach einer Inhaltsänderung, ob die Aktualisierung übernommen wurde. Kontrollieren Sie auch, ob Login-Seiten vom Cache ausgeschlossen sind.

Cloudflare 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/)

## Implementierungsvorgaben für die Programmierung mit KI

Fordern 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.

```text
Nehmen Sie den zentralen Inhalt öffentlicher Wissensseiten in das initiale HTML auf.
Prüfen Sie für öffentliche Dokumente vorrangig die statische Generierung.
Erläutern Sie die Aktualisierung veränderlicher Daten gesondert.
Prüfen Sie, ob das CDN HTML im Cache speichert.
Schließen Sie Login-, Konto- und Zahlungsseiten vom gemeinsamen Cache aus.
Verknüpfen Sie bei Inhaltsänderungen die Neugenerierung statischer Dateien mit der Cache-Aktualisierung.
Richten Sie bei mehrsprachigen Seiten hreflang-Verknüpfungen ein.
Geben Sie an, wie das initiale HTML, der Cache-Status und die Übernahme von Änderungen geprüft werden können.
```

## FAQ

### Müssen Low-Involvement-Websites mit einem bestimmten Framework erstellt werden?
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.

### Führt Google kein JavaScript aus?
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.

### Lassen sich auch mit React erstellte Websites statisch generieren?
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.

### Ist die Seite bei einer TTFB von höchstens 0.8 Sekunden vollständig geladen?
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.

### Wird eine Seite bei einer TTFB von mehr als 0.8 Sekunden aus der Google-Suche ausgeschlossen?
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.

### Ist ein Server in Korea für eine globale Website nachteilig?
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.

### Wird nach der Einbindung von Cloudflare auch HTML automatisch gecacht?
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.

### Ist auch die erste Anfrage, die nicht im CDN-Cache liegt, immer schnell?
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.

### Darf HTML-Caching auch auf Login-Seiten angewendet werden?
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.

### Was kann ich tun, wenn nach der Bearbeitung eines Beitrags auf einer statischen Website noch der alte Inhalt angezeigt wird?
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.

### Muss hreflang ausschließlich im HTML angegeben werden?
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.

### Muss das Crawling-Budget auch bei einer kleinen Website intensiv verwaltet werden?
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

- [Google Search Central: Die Grundlagen von JavaScript-SEO verstehen](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)
- [web.dev: Rendering im Web](https://web.dev/articles/rendering-on-the-web)
- [web.dev: Time to First Byte (TTFB), aktualisiert am 18. November 2025](https://web.dev/articles/ttfb)
- [Google: Überblick über die Crawler und Fetcher von Google](https://developers.google.com/crawling/docs/crawlers-fetchers/overview-google-crawlers?hl=en)
- [Google: Ihr Crawling-Budget optimieren](https://developers.google.com/crawling/docs/crawl-budget)
- [Cloudflare: Standardverhalten des Caches](https://developers.cloudflare.com/cache/concepts/default-cache-behavior/)
- [Cloudflare Cache: Erste Schritte](https://developers.cloudflare.com/cache/get-started/)
- [Cloudflare: Cache-Stufe (Cache Everything)](https://developers.cloudflare.com/cache/how-to/cache-rules/examples/cache-everything/)
- [Antworten des Cloudflare-Caches](https://developers.cloudflare.com/cache/concepts/cache-responses/)
- [Cloudflare: Cache leeren](https://developers.cloudflare.com/cache/how-to/purge-cache/)
- [Cloudflare: Probleme mit dynamischen Inhalten und der Anmeldung](https://developers.cloudflare.com/cache/troubleshooting/dynamic-content-and-login-issues/)
- [Google Search Central: Google über lokalisierte Versionen Ihrer Seite informieren](https://developers.google.com/search/docs/specialty/international/localized-versions)

## Images

![Ein Mann prüft ein Serverrack mit ordentlich gebündelten violetten Kabeln](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzgxNjYsInB1ciI6ImJsb2JfaWQifX0=--3301cc345476b9a82de57f9e5bdbad57a8717225/ai-cace8faa.webp)
![Eine Frau vergleicht Webseiten auf zwei Tablets neben einem Diagramm zur Dokumentaktualisierung.](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzgxNzIsInB1ciI6ImJsb2JfaWQifX0=--6d794cafac94909fa4ac95705b51dc5bde79c2df/ai-9e2e0147.webp)