Hosting, Domain und Cache mit der Produktionsumgebung verbinden

Hosting und Laufzeit an die Datenaktualisierung anpassen

Auch korrekter Servercode liefert keine neuen Informationen, wenn der Crawler die Domain nicht erreicht oder vom CDN einen alten Text erhält. Suche und KI verarbeiten die tatsächlich an einer URL empfangene Antwort. Hosting-, Domain- und Cache-Einstellungen sorgen mit dafür, dass diese URL weiterhin das aktuelle öffentliche Dokument liefert.

Hosting führt Dateien oder Anwendungen aus und stellt sie im Internet bereit. Statisches Hosting liefert vorab erzeugte Dateien. Node.js ist eine Umgebung zum Ausführen von JavaScript auf dem Server. Wer bei jeder Anfrage die Datenbank lesen und HTML erzeugen will, braucht eine Serverlaufzeit oder verwaltete Plattform, die diese Funktionen unterstützt.

Serverless-Funktionen führen Code beim Eintreffen einer Anfrage aus; die Plattform übernimmt den Serverbetrieb. Container bündeln Code und benötigte Laufzeitdateien für die Bereitstellung. Eine VM ist eine virtuelle Maschine, auf der Betriebssystem und Server selbst verwaltet werden können. Bei jeder Variante Grenzen für Laufzeit, Arbeitsspeicher, gleichzeitige Anfragen und Datenbankverbindungen prüfen.

Ein Kaltstart verzögert die erste Anfrage, während eine neue Ausführungsumgebung vorbereitet wird. Eine Region bezeichnet den Standortbereich der Server. Große Entfernungen zwischen Server und Datenbank können die Umlaufzeit von Abfragen erhöhen. HTML-Erzeugungszeit und Datenbankabfragezeit getrennt erfassen und anschließend Ausführungsregion, Verbindungswiederverwendung und Cache anpassen.

Mehrere Server so konfigurieren, dass sie denselben öffentlichen Text und denselben Cache-Aktualisierungsstand lesen. Unterschiedliche lokale Festplatten-Caches können dazu führen, dass dieselbe URL je Anfrage andere Artikel liefert. Cache-Freigabe und Weitergabe der Revalidierung zwischen Instanzen anhand der Next.js-Anleitung zum Self-Hosting und der Möglichkeiten der Bereitstellungsplattform einrichten. Eine Instanz bezeichnet ein laufendes Serverprogramm.

Die Produktionsadresse über DNS und HTTPS verbinden

DNS, das Domain Name System, löst einen Domainnamen zu einer Verbindungsadresse auf. Ein A-Eintrag verweist auf eine IPv4-Adresse, AAAA auf IPv6 und CNAME auf einen anderen Hostnamen. TXT enthält Textwerte, etwa für Eigentumsnachweise. Im Verwaltungsbereich des DNS-Anbieters die vom Hostingdienst verlangten Einträge setzen. Wie eine CNAME-ähnliche Verbindung an der Domainwurzel angeboten wird, unterscheidet sich je Anbieter. Siehe die Erklärung zu Domains und DNS.

TTL, Time To Live, gibt an, wie lange eine DNS-Antwort wiederverwendet werden darf. Nach einer Adressänderung können Clients mit zwischengespeichertem altem Eintrag bis zum Ablauf der TTL noch den alten Server erreichen. Vor der Umstellung den neuen Server für die kanonische Domain vorbereiten. Danach prüfen, ob alte und neue Verbindungen die beabsichtigte Seite liefern. Bei einem AAAA-Eintrag auch den IPv6-Weg prüfen.

HTTPS ist durch TLS, Transport Layer Security, geschützte HTTP-Kommunikation. Ein Zertifikat dient zur Identitätsprüfung der verbundenen Domain. Prüfen, ob Produktionsdomain und tatsächlich verwendete Namen wie www enthalten sind und Gültigkeit sowie automatische Erneuerung funktionieren. Zertifikatsfehler können Browser oder Crawler dazu bringen, die Verbindung vor dem Empfang des Inhalts abzubrechen. Die TLS-Erklärung erläutert Verbindungsschutz und die Rolle von Zertifikaten.

Eine kanonische HTTPS-URL festlegen und HTTP- sowie www-Varianten dauerhaft dorthin umleiten. DNS bestimmt den Zielserver; eine HTTP-Weiterleitung bestimmt die URL, zu der Besucher wechseln sollen. Domain- und Weiterleitungseinstellungen des Hostings getrennt prüfen. Auch Bilder, CSS und Skripte über HTTPS adressieren, um Mixed-Content-Probleme durch HTTP-Ressourcen innerhalb einer sicheren Verbindung zu reduzieren.

Öffentliche Dokumente durch CDN, Proxy und WAF lassen

Ein Reverse Proxy nimmt Anfragen vor einem Server entgegen und leitet sie an einen internen Server weiter. Ein Load Balancer verteilt Anfragen auf mehrere Server. Ein CDN-Edge verarbeitet Anfragen in der Nähe der Nutzer. Eine Plattform kann diese Rollen kombinieren. Zuerst die Dienste aufzeichnen, die aktuelle Anfragen durchlaufen.

Eine WAF, Web Application Firewall, prüft HTTP-Anfragen und blockiert solche, die sie als Angriff einstuft. Ein Rate Limit begrenzt die Zahl der Anfragen in einem Zeitraum. Eine Bot-Challenge verlangt einen menschlichen Klick oder die Ausführung von Browsercode. Erscheint sie vor einem öffentlichen Artikel, erhält der Crawler möglicherweise die Prüfaufforderung statt des Artikels.

In den Anfrageprotokollen von CDN und WAF blockierte Pfade, Zeitpunkte, Regeln und Statuscodes suchen. Die betreffenden Regeln so anpassen, dass öffentliche Artikel, robots.txt, Sitemaps und benötigte Bilder regulär ausgeliefert werden. Authentifizierung für Verwaltung und Entwürfe sowie Angriffsschutz beibehalten. Bei der Freigabe von Suchbots nicht allein dem Namensstring vertrauen, sondern die veröffentlichten IP-Bereiche oder Prüfverfahren des Betreibers verwenden.

Google-Anfragen lassen sich mit offiziellen IP-Listen abgleichen. Alternativ den Namen per Reverse DNS ermitteln und prüfen, ob die anschließende Vorwärtsauflösung wieder die ursprüngliche IP ergibt. Googles Anleitung zur Crawler-Prüfung enthält Verfahren je Bot-Typ. User-Agent ist eine vom anfragenden Programm gesendete Kennung; andere Programme können denselben Namen senden.

Weitergeleitete Host- und Protokollinformationen nur von vertrauenswürdigen Proxys übernehmen. Kanonische URLs aus der festgelegten Produktionsdomain erzeugen. Auch prüfen, ob CDN oder Proxy Fehlerantworten in 200 ändern oder alle unbekannten Pfade zur Startseite schicken. Unterscheiden sich Ursprungs- und vorgelagerte Antwort, vergleichen, welche Stufe Statuscode, Header oder Inhalt verändert hat.

Ein Browser kann beispielsweise nach einem Bestätigungsklick den Artikel öffnen, während eine automatische Crawl-Anfrage nur die Prüfseite erhält. Dann erreicht selbst per SSR erzeugter Inhalt den Crawler nicht. Der Vergleich einer 200-Antwort des Ursprungsservers mit 403 oder Prüf-HTML über das CDN zeigt, ob die Inhaltserzeugung oder die Zugriffssperre korrigiert werden muss.

Dokumente, Umzüge und Fehler mit korrekten Statuscodes beantworten

Statuscodes übermitteln das Ergebnis einer HTTP-Anfrage als dreistellige Zahl. Ein regulärer Artikel verwendet 200 samt Inhalt, ein dauerhafter Umzug 301 oder 308, ein fehlendes Dokument 404. 410 bedeutet, dass eine Ressource dauerhaft verschwunden ist. Nach Löschrichtlinie des Dienstes und Framework-Unterstützung auswählen.

Ein Soft 404 liefert Status 200, sieht aber wie ein leeres Dokument oder eine Fehlermeldung aus. Das kann entstehen, wenn unbekannte Slugs durch die Startseite ersetzt oder Datenbankfehler als leere Artikel behandelt werden. Tatsächlich fehlende Dokumente und vorübergehende Abfragefehler in der Antwort unterscheiden. Googles Behandlung von Statuscodes erklärt die Auswirkungen der einzelnen Codes auf das Crawling.

Vorübergehende Serverfehler mit 5xx melden und ihre Ursache beheben. Für Anfragelimits kann 429, für vorübergehende Dienstunterbrechungen situationsabhängig 503 verwendet werden. Retry-After nennt eine Wartezeit oder einen Zeitpunkt für die nächste Anfrage. Wiederholte Beschränkungen können auch reguläres Crawling verringern. Deshalb Fehlerrate und Verarbeitungskapazität gemeinsam prüfen.

Cache-Speicherorte und Aktualisierungsbedingungen festlegen

Caches können im Browser, im CDN sowie für Datenabfragen und erzeugte Seiten der Anwendung bestehen. Ein Cache-Schlüssel identifiziert ein gespeichertes Ergebnis. Variiert eine Antwort zusätzlich zur URL nach Sprache, Nutzer oder Query, diese Unterschiede im Schlüssel abbilden oder gemeinsame Speicherung vermeiden. Cache-Control steuert HTTP-Caches; frameworkinterne Datencaches werden separat aktualisiert.

max-age ist die Zeit in Sekunden, in der eine Antwort als frisch wiederverwendet werden darf. s-maxage gilt für gemeinsame Caches wie CDNs. private erlaubt nur nutzerspezifische Caches, no-store verbietet die Speicherung der Antwort. no-cache erlaubt Speicherung, verlangt vor Wiederverwendung aber eine Gültigkeitsprüfung beim Server. Ähnliche Namen bedeuten unterschiedliche Abläufe. Antwortheader anhand der Erklärung zu HTTP-Caching auswählen.

ETag ist ein Prüfwert zur Identifikation einer Antwortversion; Last-Modified ist deren Änderungszeit. Ergibt eine bedingte Anfrage mit gespeicherten Werten unveränderten Inhalt, kann der Server 304 zurückgeben. Vary teilt Caches mit, welche Anfrageheader die Antwort beeinflussen. Wer von der Plattform benötigte Vary-Werte entfernt, kann Antworten verschiedener Anfragen vermischen. Im HTTP-Caching-Standard die Bedingungen für Prüfung und Speicherung nachlesen.

stale-while-revalidate erlaubt innerhalb eines festgelegten Zeitraums eine alte Antwort, während im Hintergrund aktualisiert wird. immutable ist für Ressourcen vorgesehen, deren Inhalt während ihrer Gültigkeit unverändert bleibt. Für öffentliche CSS- und JavaScript-Dateien mit Inhaltshash im Dateinamen können lange Cache-Zeiten passen. Bei korrigierbaren oder zurückziehbaren Texten und Fotos zuerst die zulässige Nachhaltezeit und das Verfahren zur Invalidierung bestimmen.

Revalidierung prüft, ob gespeicherte Inhalte weiterhin gültig sind, oder erzeugt ein neues Ergebnis. Invalidierung und Purge verhindern die weitere Nutzung alter Cache-Einträge. Nach einer CMS-Veröffentlichung Daten- und Seitencaches für Detailansicht, Liste und Sitemap aktualisieren. Speichert ein externes CDN zusätzlich, auch dessen Aktualisierung anbinden. Die Next.js-Cache-Anleitung passend zur installierten Version anwenden.

Material, das unmittelbar nach Rücknahme unzugänglich sein muss, so ausliefern, dass auch bei vorhandenen Caches der Veröffentlichungsstatus geprüft wird. Bereits vom Browser heruntergeladene Dateien kann der Server nicht zurückholen. Festlegen, was Server und CDN bei neuen Anfragen zurückgeben und wann die Sperre greift. In mehreren Regionen sowie mit Erst- und Folgeanfragen prüfen.

Ändert sich die Schließzeit von 17 auf 16 Uhr, liefert das CDN aber altes HTML, lesen auch später eintreffende Crawler noch 17 Uhr. Nur dateModified auf heute zu setzen, kann die ausgelieferte Tatsache unverändert lassen. Deshalb nach dem Speichern den Cache aktualisieren und Öffnungszeit sowie revision in der tatsächlichen Antwort prüfen. Anschließend den letzten Crawl-Zeitpunkt der externen Suche mit dem zitierten Originaltext vergleichen.

Umgebungsvariablen, Bereitstellung und Logs an der Produktionsadresse ausrichten

Umgebungsvariablen liefern Konfiguration außerhalb des Codes. Produktionsdomain, Datenbankadresse, Speicherschlüssel und andere Werte nach Entwicklung, Vorschau und Produktion trennen. Next.js-Werte mit dem Präfix NEXT_PUBLIC_ können im Browsercode enthalten sein und werden beim Build festgelegt. Geheime Schlüssel bleiben serverseitig. Einstellungen zur Erzeugung öffentlicher URLs müssen zur Produktionsdomain passen.

CI, Continuous Integration, führt beim Zusammenführen von Änderungen automatisch Prüfungen und Builds aus. CD, Continuous Delivery oder Deployment, bereitet Ergebnisse zur Bereitstellung vor oder stellt sie bereit. Ein Artefakt ist eine im Build erzeugte Bereitstellungsdatei. Getestetes und tatsächlich bereitgestelltes Ergebnis über eine Versionskennung miteinander verknüpfen.

Preview und Staging sind Prüfumgebungen vor dem Produktionsbetrieb. Den Umfang ihrer Nutzung von Produktionsdaten und Geheimnissen festlegen und den Zugriff durch Authentifizierung beschränken. Prüfen, dass Einstellungen zum Suchausschluss nicht in Produktion übernommen werden. Nach einer Änderung der Domainanbindung Inhalt, Header und Assets erneut über die Produktionsdomain anfordern.

Logs zeichnen Anfragen und Verarbeitungsergebnisse auf. Statuscode, Pfad, Verarbeitungszeit, Antwortumfang und Bereitstellungsversion erfassen. Mit einer Anfrage-ID die Verarbeitung in CDN, Anwendung und Datenbank verbinden. Ein Timeout beendet Arbeit, die nicht rechtzeitig fertig wurde. Bei langsamer Inhaltserzeugung Datenbankabfragen, externe APIs und Bildverarbeitung getrennt untersuchen.

Monitoring beobachtet Fehlerraten, Verzögerungen und andere Signale fortlaufend. Alerts benachrichtigen Verantwortliche, wenn festgelegte Bedingungen überschritten werden. Zunehmende 5xx bei regulären öffentlichen Artikeln, ablaufende Zertifikate und gescheiterte Cache-Aktualisierungen nach Veröffentlichung überwachen. Frühere Bereitstellung und Datenbanksicherung für Störungen festlegen. Nach der Wiederherstellung die tatsächlichen öffentlichen URLs erneut prüfen.

Caches für öffentliche Dokumente und nutzerspezifische Antworten trennen

Gemeinsame Caches sind möglich, wenn die Antwort für alle gleich ist und eine gewisse Verzögerung akzeptiert wird. Bei vom Anmeldestatus abhängigen Antworten und sofort zurückzuziehendem Material gemeinsame Speicherung vermeiden oder vor der Ausgabe Berechtigungen prüfen. Werden Framework-Header durch vorgelagerte Systeme überschrieben, auch das resultierende Verhalten prüfen.

Beispielsweise kann Cache-Control: private, no-store die Speicherung privater Nutzerdaten verhindern. Öffentliche Assets, deren URL sich mit dem Inhalt ändert, können langes max-age und immutable verwenden. Die Cache-Zeit für öffentliches HTML erst nach Festlegung der zulässigen Änderungsverzögerung und der Invalidierungsmöglichkeiten wählen. Geänderte HTTP-Header aktualisieren einen internen Datenbankabfrage-Cache nicht automatisch.

Caches nach Abschluss der Veröffentlichung aktualisieren

Die Route für aktuelle Artikel in der Übung verwendet force-dynamic und rendert jede Anfrage neu. Bei gecachten CMS-Abfragen oder statischen beziehungsweise ISR-Routen die Revalidierung nach abgeschlossenem Speichern aufrufen. Die folgende Funktion wird in der serverseitigen Veröffentlichung nach Authentifizierung und Berechtigungsprüfung verwendet.

// lib/refresh-guide.ts — cacheComponents: false Konfiguration import { revalidatePath } from 'next/cache' export function refreshGuide(slug: string) { if (!/^[a-z0-9]+(?:-[a-z0-9]+)*$/.test(slug)) { throw new Error('Invalid slug') } revalidatePath(`/guides/${slug}`) revalidatePath('/') revalidatePath('/sitemap.xml') } // Reihenfolge: Nutzerberechtigung prüfen → Veröffentlichung in der Datenbank fertig speichern → refreshGuide(slug)

revalidatePath fordert die Revalidierung eines Pfads an. Je nach Aufrufort und Cache-Konfiguration erfolgt die Aktualisierung möglicherweise beim nächsten Besuch. Ein separates CDN nutzt den Invalidierungsmechanismus seiner Plattform. Lesen mehrere Seiten Daten mit demselben Tag, auch tagbasierte Aktualisierung prüfen. Den Geltungsbereich der revalidatePath-Anleitung mit der tatsächlich ersten erneuten Anfrage vergleichen.

Bei aktiviertem Cache Components Lebensdauer und Aufruforte von cacheLife, cacheTag, revalidateTag und updateTag gesondert wählen. Eine Revalidierung, die zunächst alte Inhalte liefert, verhält sich anders als sofortiger Ablauf. Bei Rücknahmen auch prüfen, ob das CDN alte Dokumente zurückgibt, bevor die Anfrage den Ursprungsserver erreicht. Die Revalidierungsanleitung für das verwendete Cache-Modell lesen.

Die Funktion in der serverseitigen Veröffentlichung nach abgeschlossenem Datenbankspeichern aufrufen. Sie prüft den Slug und aktualisiert dann die Caches von Detailseite, Startseite und Sitemap. Ein Aufruf vor dem Speichern kann noch unveränderte Inhalte erneut cachen. Zeigt eine Folgeanfrage weiterhin die alte revision, Next.js-Cache und externes CDN getrennt prüfen. Bei datenbankgestützten Diensten nach Veröffentlichung und Rücknahme Detailseite, Liste und Sitemap erneut abrufen und Veröffentlichungsstatus sowie Inhalt vergleichen.

Wer nur die Detailseite revalidiert, kann alte Zusammenfassungen auf der Startseite oder alte Sitemap-Daten behalten. refreshGuide umfasst Detailseite, Startseite und Sitemap, damit die von einer Veröffentlichung veränderten öffentlichen Ausgaben gemeinsam aktualisiert werden. Werden weitere Daten oder Caches für Routen ergänzt, diese Routen ebenfalls in die Aktualisierungsbeziehung aufnehmen.

Cache-Fehler anhand von Quelle und öffentlicher Antwort unterscheiden

Die Übung zu öffentlichen Daten vergleicht im zweiten Test Quell- und Cache-Abfrage zum selben Zeitpunkt. Nennt die Quelle 10–16 Uhr und der Cache 10–17 Uhr, war das Speichern erfolgreich, die Auslieferung wurde jedoch nicht aktualisiert. Dann den Cache des betroffenen Pfads invalidieren, statt den Redakteur erneut speichern zu lassen.

Auch wenn die Detailseite nach Rücknahme 404 liefert, kann der Artikel in Listen- und Sitemap-Caches verbleiben. Den Speichercache mit clearCache leeren. Bei zusätzlichem CDN Dokument-ID, revision und zu aktualisierende Pfade im Veröffentlichungsvorgang erfassen und die Invalidierungs-API des CDNs aufrufen. Fehlgeschlagene Anfragen wiederholen. Prüfen, ob unmittelbar nach Rücknahme auch über die CDN-URL 404 oder eine Zugriffssperre zurückkommt.

HTTP-Speicherverbot und serverseitige Bildwiederverwendung gemeinsam betrachten

Eine Transformation bei jedem Bildabruf dekodiert und kodiert dieselbe Quelle wiederholt. Intern gespeicherte Transformationsergebnisse reduzieren diesen Aufwand. no-store in einer HTTP-Antwort weist empfangende Caches an, die Antwort nicht zu speichern. Die Wiederverwendung derselben abgeleiteten Datei im privaten Speicher des Servers hat einen anderen Speicherort und Zugriffsweg. Cache-Control

In der Bildübung liefern zwei Anfragen an /media/photo?w=640 jeweils private, no-store, max-age=0. Der Serverwert transforms ist 1. Auch die zweite Anfrage erhält Bildbytes, aber der Server transformiert nicht erneut. Das geringere Übertragungsvolumen entsteht durch das kleine WebP; der geringere Serveraufwand durch die Wiederverwendung des Transformationsergebnisses.

Zurückziehbares Material benötigt einen Zugriffsweg, der bei jeder Anfrage den aktuellen Veröffentlichungsstatus prüft. Bereits im öffentlichen CDN gespeicherte Dateien können ohne Prüfung durch den Ursprungsserver ausgeliefert werden. Bei dauerhaft öffentlichen Assets wie einem Logo mit inhaltsgehashter URL kann langfristiges Caching dagegen die Übertragung reduzieren. Zuerst Änderungs- und Rücknahmeanforderungen festlegen, dann Antwortcache und Speicher wählen.

setPublished im Übungsspeicher ändert den prozessinternen Zustand. In einer Datenbankumgebung prüfen, ob neue Anfragen nach Abschluss der Veröffentlichungstransaktion diesen Zustand lesen. Wurde ein externes CDN ergänzt, nach Rücknahme Original- und Derivat-URLs auch darüber abrufen und verbliebene Dateien sowie Invalidierungsergebnisse prüfen.