Statische vs. dynamische Websites: Unterschiede, Beispiele und die richtige Wahl

Der Hauptunterschied zwischen statischen und dynamischen Websites liegt darin, wann und wo ihre Inhalte erstellt werden. Statische Seiten werden vorbereitet, bevor ein Besucher sie aufruft. Dynamische Seiten erstellen oder laden Inhalte zur Laufzeit – auf einem Server oder im Browser des Besuchers.

Dieser Unterschied wirkt sich auf die Veröffentlichung, das Hosting, das Caching und den Zugriff auf aktuelle Informationen aus. Er sagt jedoch nichts darüber aus, ob eine Website Animationen enthalten, Formularübermittlungen annehmen oder ein Einkaufserlebnis bieten kann. Solche Funktionen hängen vom Code und den mit den Seiten verbundenen Diensten ab.

Wer eine Website erstellt oder migriert, sollte sich fragen, welcher Ansatz am besten zu den Aufgaben der Website passt. Eine Produkt-Landingpage, ein Echtzeit-Buchungskalender und ein Kunden-Dashboard haben unterschiedliche Anforderungen – selbst wenn sie zum selben Unternehmen gehören.

Dieser Leitfaden vergleicht die beiden Ansätze, erklärt ihre Überschneidungen und zeigt, wie wir statische Seiten und datengesteuerte Websites mit TeleportHQ umsetzen.

In diesem Leitfaden#

• Statische vs. dynamische Websites auf einen Blick
• Was ist eine statische Website?
• Was ist eine dynamische Website?
• Können statische Websites dynamische Funktionen haben?
• Statisch oder dynamisch: die praktischen Abwägungen
• SEO, KI-Übersichten und Sichtbarkeit in großen Sprachmodellen
• Beispiele für Website-Baukästen, CMS und Frameworks
• Wie TeleportHQ mit statischen und dynamischen Websites umgeht
• Welchen Ansatz sollten Sie wählen?
• Häufig gestellte Fragen

Statische und dynamische Websites auf einen Blick#

Eine statische Seite liefert ein bereits generiertes Dokument aus. Eine serverseitig gerenderte dynamische Seite erstellt ein Dokument bei Bedarf. Eine Seite kann auch Daten im Browser laden, nachdem das ursprüngliche Dokument ausgeliefert wurde.

Diese Ansätze können miteinander kombiniert werden. Ein Online-Shop kann beispielsweise Produktbeschreibungen vorab generieren, den aktuellen Lagerbestand über eine API abrufen und Bestellungen über ein Backend verarbeiten.

Die Kategorien beschreiben die Wahl der Implementierung. Sie unterscheiden weder kleine von großen Websites noch einfache Designs von anspruchsvollen Nutzererlebnissen.

Was ist eine statische Website?#

Eine statische Website liefert Seiten aus, die bereits vorhanden sind, wenn Besucher sie aufrufen. Diese Seiten enthalten HTML für die Struktur, CSS für die Darstellung und häufig JavaScript für Interaktionen.

Die Dateien können von einem Webserver ausgeliefert oder über ein Content Delivery Network verteilt werden, meist CDN genannt. Da das Dokument bereits vorbereitet ist, muss es für jeden Besuch nicht aus Datenbankeinträgen neu erstellt werden.

„Statisch“ bedeutet nicht, dass die Inhalte für immer unverändert bleiben müssen. Du kannst die Quelldateien aktualisieren, neue Dateien generieren und sie so oft veröffentlichen, wie es dein Arbeitsablauf erlaubt.

So werden statische Seiten erstellt#

Es gibt verschiedene Möglichkeiten, sie zu erstellen:

• HTML direkt schreiben. Das eignet sich für kleine Projekte, wird aber ohne Vorlagen schnell repetitiv.
• Einen visuellen Builder verwenden. Inhalte und Layouts über eine Benutzeroberfläche bearbeiten und anschließend die generierten Dateien veröffentlichen.
• Einen Generator für statische Websites verwenden. Vorlagen mit Markdown, strukturierten Dateien oder API-Daten kombinieren, um Seiten zu erstellen.
• Ein Content-Management-System anbinden. Redakteure aktualisieren Inhalte im CMS, und ein Build-Prozess erzeugt daraus die öffentlich zugänglichen Seiten.

A Ein Generator für statische Websites kann aus einem wiederverwendbaren Layout viele Seiten erstellen. Ein Kurskatalog mit 300 Kursen erfordert nicht unbedingt, dass jemand 300 separate Dokumente von Hand gestaltet und pflegt.

Die Inhalte können aus einer Datenbank stammen. Statisch sind die resultierenden Seiten deshalb, weil ihr HTML bereits vor der Auslieferung generiert wird, anstatt für jede Anfrage eines Besuchers neu zusammengesetzt zu werden.

Vorteile statischer Websites#

• Einfache Auslieferung: Vorbereitete Dateien können ausgeliefert werden, ohne bei jeder Anfrage die Anwendung zur Seitenerstellung auszuführen.
• Effizientes Caching: gemeinsam genutzte Dateien eignen sich gut für die Bereitstellung über ein CDN.
• Potenziell niedrigere Betriebskosten: Für öffentliche Inhalte ist nicht unbedingt ein dauerhaft laufender Anwendungsserver erforderlich.
• Flexibles Design: Vorlagen und Komponenten ermöglichen unterschiedliche Layouts auf der Website.
• Weniger öffentliche Laufzeitkomponenten: Die ausgelieferten Seiten geben möglicherweise weniger serverseitige Anwendungslogik preis.

Zu berücksichtigende Einschränkungen#

Updates erfordern einen Veröffentlichungsprozess, der die generierten Dateien aktuell hält. Bei einer großen Website kann es umständlich werden, nach jeder kleinen Änderung alles neu zu erstellen. Deshalb ist die Build-Strategie wichtig.

Statische Dateien können außerdem nicht eigenständig Zahlungen sicher verarbeiten, Kontoberechtigungen überprüfen oder gemeinsam genutzte Kundendaten speichern. Für solche Vorgänge ist ein Backend erforderlich, das Sie selbst verwalten oder als gehosteten Dienst nutzen können.

Eine statische Architektur eignet sich besonders gut für öffentliche Inhalte, die im Voraus erstellt werden können: Serviceseiten, Artikel, Dokumentationen, Portfolios und viele Produktbeschreibungen.

Was ist eine dynamische Website?#

Eine dynamische Website nutzt Logik zur Laufzeit, um Inhalte zu erstellen oder abzurufen. Sie kann auf die Anfrage eines Besuchers, sein Konto, ausgewählte Filter oder die neuesten Informationen in einer Datenbank reagieren.

Das bedeutet nicht, dass jede dynamische Seite personalisiert ist. Ein Server kann denselben öffentlichen Artikel für Tausende Besucher generieren. Die Seite wird dennoch dynamisch erstellt, wenn die Anwendung sie erst zum Zeitpunkt der Anfrage zusammensetzt, anstatt eine zuvor erstellte Datei auszuliefern.

So funktionieren dynamische Seiten#

Zwei gängige Verfahren sind:

• Serverseitiges Rendering: Der Server führt Anwendungslogik aus, ruft die benötigten Daten ab und liefert HTML mit dem Seiteninhalt zurück.
• Clientseitiges Rendering: JavaScript im Browser erstellt oder aktualisiert die Benutzeroberfläche und nutzt dafür häufig Daten, die über eine API abgerufen werden.

Viele Anwendungen kombinieren beides. Ein Server kann eine vollständige erste Seite zurückgeben. Anschließend übernimmt der Browsercode Filter, aktualisiert Diagramme oder lädt weitere Ergebnisse.

Ein Studierenden-Dashboard könnte beispielsweise prüfen, wer sich angemeldet hat, die belegten Kurse abrufen und den Lernfortschritt anzeigen. Ein anderer Studierender erhält über dieselbe Benutzeroberfläche andere Daten.

Vorteile dynamischer Websites#

• Aktuelle Informationen: Seiten können kürzlich aktualisierte Datensätze verwenden, statt auf einen vollständigen Neuaufbau der Website zu warten.
• Dauerhafte Aktionen: Besucher können über Backend-Dienste Konten erstellen, Bestellungen aufgeben oder Einstellungen speichern.
• Personalisierte Erlebnisse: Berechtigte Nutzer können ihre eigenen Käufe, Nachrichten und Einstellungen sehen.
• Strukturierte Inhaltsverwaltung: Gemeinsame Vorlagen zeigen Datensätze aus einer zentralen Quelle an.
• Anwendungsabläufe: Ein übermitteltes Formular kann eine Validierung, Datenbankaktualisierungen und Folgeaktionen auslösen.

Zu berücksichtigende Einschränkungen#

Funktionen zur Laufzeit bringen Abhängigkeiten mit sich. Eine langsame Datenbankabfrage, eine nicht verfügbare API oder ein überlasteter Anwendungsserver können das Besuchererlebnis beeinträchtigen.

Das Team muss außerdem Berechtigungen, Datenspeicherung, Software-Updates, Überwachung und Wiederherstellungsprozesse verwalten. Eine verwaltete Plattform kann einen großen Teil der Infrastruktur übernehmen, doch die Logik der Website muss weiterhin korrekt konfiguriert werden.

Weder eingeschränkte Gestaltungsfreiheit noch eine schlechte Suchmaschinenperformance sind grundsätzlich eine Eigenschaft dynamischer Websites. Diese Ergebnisse hängen von der Plattform, der Umsetzung und den Wartungsentscheidungen ab.

Können statische Websites dynamische Funktionen haben?#

Ja. Eine Website kann statisches HTML ausliefern und dennoch interaktive oder datengesteuerte Funktionen bieten. Entscheidend ist die Unterscheidung zwischen dem, was auf der Seite geschieht, und dem, was in den dahinterliegenden Diensten passiert.

An diesem Punkt werden viele Erklärungen zum Unterschied zwischen statischen und dynamischen Websites verwirrend. Wenn sich ein Menü per Klick öffnet, verändert das die Benutzeroberfläche, erfordert aber nicht, dass der Server ein neues Dokument generiert. Ein Zahlungsformular kann auf einer statischen Seite angezeigt werden, während die Zahlung selbst von einem separaten Dienst verarbeitet wird.

Interaktionen im Browser erfordern keine dynamische Seitengenerierung#

JavaScript und CSS ermöglichen Interaktionen wie:

• Navigationsmenüs und Akkordeons öffnen.
• Zwischen Tabs wechseln.
• Elemente beim Scrollen animieren.
• Eine Preisschätzung anhand von Werten berechnen, die bereits auf der Seite verfügbar sind.
• Eine bereits geladene Liste filtern.
• Eine lokale Anzeigeeinstellung im Browser speichern.

Diese Funktionen können mit vorgefertigten Seiten umgesetzt werden. Sie benötigen nicht unbedingt eine Datenbank oder einen Anwendungsserver.

Für dauerhafte Funktionen müssen Daten verarbeitet und gespeichert werden#

Bei einigen Aktionen geht es um Informationen, die über die aktuelle Browsersitzung hinaus bestehen oder für mehrere Nutzer zugänglich sein müssen. Beispiele sind:

• Eine Kontaktanfrage empfangen und speichern.
• Anmeldedaten überprüfen.
• Einen Kauf bestätigen.
• Einen Termin speichern.
• Inventar wird aktualisiert.
• Der Bestellverlauf eines Kunden wird angezeigt.

Ein statisches Frontend kann mit Diensten verbunden werden, die diese Vorgänge ausführen. Das Frontend wird weiterhin statisch ausgeliefert, während das Gesamtsystem dynamische Funktionen umfasst.

Für die Authentifizierung reicht es außerdem nicht aus, ein Element mit JavaScript auszublenden. Ein Backend muss den Zugriff auf geschützte Informationen durchsetzen. Vertrauliche Datensätze an jeden Browser zu senden und sie lediglich visuell auszublenden, schützt diese Datensätze nicht.

Eine hybride Website kombiniert Bereitstellungsansätze#

Stellen Sie sich ein Unternehmen vor, das Onlinekurse verkauft:

1. Kursbeschreibungen können im Voraus generiert werden, da sich der öffentliche Lehrplan nicht für jeden Besucher ändert.
2. Verfügbare Plätze können aus den aktuellen Anmeldedaten abgerufen werden.
3. Der Bezahlvorgang erfordert eine Backend-Validierung und Zahlungsabwicklung.
4. Das Dashboard der Studierenden zeigt nach der Authentifizierung private Datensätze an.

Dieselbe Website kann gemeinsam genutzte öffentliche Inhalte, aktuelle Betriebsdaten und private Anwendungsfunktionen umfassen. Es bringt wenig, jeden Bereich in dieselbe Rendering-Strategie zu zwingen.

Bei der Bewertung von Tools begegnen Ihnen möglicherweise die Begriffe SSG, SSR und CSR. SSG steht für statische Seitengenerierung, SSR für serverseitiges Rendering und CSR für clientseitiges Rendering. Sie beschreiben, wie Inhalte auf die Seite gelangen, und ein einzelnes Projekt kann mehr als eine dieser Methoden verwenden.

Manche Systeme generieren ausgewählte Seiten nach der Veröffentlichung erneut oder speichern dynamisch generierte Antworten im Cache. Fragen Sie bei der Bewertung dieser Optionen, wie aktuell die Inhalte sein müssen und was zwischen einer Aktualisierung und der nächsten Anfrage eines Besuchers geschieht.

Statisch oder dynamisch: die praktischen Abwägungen#

Der beste Vergleich geht von den Anforderungen Ihrer Website aus. Geschwindigkeit ist wichtig, ebenso aber Inhaltsaktualisierungen, Zuverlässigkeit, Datenaktualität und der Zeitaufwand für die Wartung der Website.

Leistung und Ladegeschwindigkeit#

Bei der statischen Auslieferung muss das anfängliche Dokument nicht für jede Anfrage neu erstellt werden. Das kann die Serverlast senken und die Verteilung öffentlicher Seiten über ein CDN erleichtern.

Eine statische Seite kann dennoch langsam sein, wenn sie übergroße Bilder, zu viel JavaScript, unnötige Schriftarten oder umfangreiche Skripte von Drittanbietern lädt. Vorgefertigtes HTML verhindert weder langsame Seiten noch eine träge Benutzeroberfläche.

Dynamische Seiten können gute Leistung bieten, wenn Abfragen, Anwendungscode und Caching passend gestaltet sind. Gemeinsam genutzte öffentliche Antworten lassen sich oft zwischenspeichern, wodurch sich wiederholte Verarbeitung vermeiden lässt.

Vergleichen Sie die tatsächliche Nutzungserfahrung:

• Wie schnell werden die Hauptinhalte über eine mobile Verbindung angezeigt?
• Bleibt die Seite während der Interaktionen reaktionsfähig?
• Verschiebt sich das Layout, während Bilder, Schriftarten oder Einbettungen geladen werden?
• Was passiert, wenn eine API oder Datenbank langsam antwortet?

Messen Sie repräsentative Seiten, einschließlich Übersichts- und Detailseiten. Eine schnelle Startseite belegt nicht, dass die gesamte Website leistungsfähig ist.

Veröffentlichung und Aktualität der Inhalte#

Statische Inhalte ändern sich in der Regel, wenn Dateien neu generiert oder veröffentlicht werden. Dies kann automatisiert durch eine Aktualisierung im CMS ausgelöst werden, anstatt dass ein Entwickler HTML manuell bearbeitet.

Dynamische Seiten können aktuelle Informationen abrufen, doch Caches können weiterhin verzögern, wann Besucher Änderungen sehen. „Dynamisch“ bedeutet nicht automatisch „sofort“.

Wählen Sie das Aktualisierungsmodell entsprechend den Folgen veralteter Informationen:

• Eine Mitarbeiterbiografie kann normalerweise bis zur Veröffentlichung warten.
• Eine Kursbeschreibung muss möglicherweise zeitgesteuert veröffentlicht werden.
• Für Bestandszahlen ist eine klare Aktualisierungsregel erforderlich.
• Bei einer Buchung oder einem Kauf muss die Verfügbarkeit zum Zeitpunkt der Transaktionsverarbeitung überprüft werden.

Die öffentliche Darstellung und die Genauigkeit bei Transaktionen sind getrennte Aufgaben. Selbst eine scheinbar aktuelle Verfügbarkeitsanzeige sollte eine serverseitige Prüfung vor der Buchungsbestätigung nicht ersetzen.

Bearbeitung, Vorlagen und Skalierung#

Beide Ansätze unterstützen strukturierte Inhalte und wiederverwendbare Layouts. Ein statischer Seitengenerator kann Tausende Seiten aus Datensätzen erstellen, während eine dynamische Anwendung viele Datensätze mit einer Vorlage darstellen kann.

Für Redakteure sind praktische Fragen oft hilfreicher als die Bezeichnung der Architektur:

• Können sie Inhalte aktualisieren, ohne den Code zu ändern?
• Können sie Änderungen vor der Veröffentlichung in der Vorschau ansehen?
• Können sie ein Layout für eine Inhaltskategorie wiederverwenden?
• Können sie Veröffentlichungen planen und Berechtigungen verwalten?
• Können sie eine gemeinsam genutzte Komponente korrigieren, ohne jede Seite bearbeiten zu müssen?

Bei großen Projekten unterscheiden sich die Engpässe. Bei statischen Projekten sind möglicherweise gezielte Builds und eine effiziente Verarbeitung von Assets erforderlich. Bei dynamischen Projekten können eine Optimierung von Abfragen, Caching und ausreichende Laufzeitkapazitäten nötig sein.

Sicherheit und Wartung#

Eine öffentliche Website, die aus statischen Dateien besteht, muss Besuchern kein aktives CMS oder Backend zur Seitengenerierung zugänglich machen. Dadurch sinkt das Risiko bestimmter Laufzeitbedrohungen.

Das gesamte System ist dadurch jedoch nicht vor Angriffen geschützt. Hosting-Konten, Build-Systeme, Abhängigkeiten, eingebettete Skripte, Formulare und verbundene Dienste müssen weiterhin abgesichert werden.

Dynamische Funktionen bringen zusätzliche Anforderungen an die Zugriffskontrolle und den Umgang mit gespeicherten Informationen mit sich. Prüfen Sie insbesondere, wer Datensätze lesen, erstellen, ändern und löschen darf. Die Authentifizierung identifiziert einen Benutzer; die Autorisierung legt fest, was dieser Benutzer tun darf.

Auch beim Caching ist Sorgfalt geboten. Gemeinsam genutzte öffentliche Inhalte lassen sich häufig für mehrere Anfragen wiederverwenden. Private Kontodaten dürfen jedoch nicht über einen falsch konfigurierten Cache an andere Besucher ausgeliefert werden.

Entwicklungskosten und laufende Kosten#

Die statische Auslieferung kann kostengünstig sein, insbesondere bei öffentlichen Informationsseiten. Das Gesamtbudget kann dennoch ein CMS, Formulare, eine Suche, Analysen, Build-Infrastruktur und laufende Entwicklungsarbeit umfassen.

Dynamische Websites bringen Anforderungen an Anwendungen und Daten mit sich, doch verwaltete Plattformen können den Betriebsaufwand verringern. Ein gut gepflegtes Content-System kann außerdem viel Zeit bei der redaktionellen Arbeit sparen.

Schätzen Sie die Kosten für den gesamten Arbeitsablauf:

• Erstimplementierung und Migration der Inhalte.
• Hosting, Datenbanken und Abonnements von Drittanbietern.
• Content-Erstellung und regelmäßige Aktualisierungen.
• Wartung, Überwachung und Support.
• Künftige Änderungen an Funktionen oder Hosting.

Der günstigste Hosting-Tarif ist nicht unbedingt die kostengünstigste Lösung, wenn jede Änderung an Inhalten manuelle Entwicklungsarbeit erfordert.

SEO, KI-Übersichten und Sichtbarkeit in LLMs#

Die Website-Architektur beeinflusst, wie einfach Suchsysteme Ihre Inhalte entdecken und darauf zugreifen können. Das kann erhebliche Auswirkungen haben, wenn eine Implementierung nützliche Informationen hinter der Ausführung im Browser, fehlerhaften Links oder eingeschränkten Zugriffspfaden verbirgt.

Die Architektur allein bestimmt jedoch weder Rankings noch die Aufnahme in KI-Antworten oder Markennennungen. Sowohl statische Seiten als auch dynamische, serverseitig gerenderte Seiten können öffentlich zugängliche Inhalte bereitstellen.

Die Hauptinhalte im zurückgegebenen HTML bereitstellen#

Prüfen Sie bei einem öffentlichen Artikel, einer Kategorieseite oder einer Serviceseite, was der Server zurückgibt, bevor das JavaScript des Browsers ausgeführt wird. Enthält die Antwort tatsächlich die Überschrift, die Erläuterung und die Links oder nur das leere Grundgerüst der Anwendung?

Vorgerenderte und serverseitig gerenderte Seiten können beide aussagekräftiges HTML zurückgeben. Der Zeitpunkt der Generierung unterscheidet sich, doch in beiden Fällen kann ein Crawler nützliche Inhalte erhalten.

Google kann JavaScript rendern, doch dadurch kommt ein zusätzlicher Verarbeitungsschritt mit entsprechenden Implementierungsaspekten hinzu. Andere Bots führen es möglicherweise nicht aus. Googles Leitfaden zu JavaScript-SEO empfiehlt, für Nutzer und Crawler serverseitiges Rendering oder Prerendering in Betracht zu ziehen.

Die praktische Empfehlung lautet, wichtige öffentliche Inhalte bereitzustellen, ohne dass Besucher zuerst auf ein Steuerelement klicken oder eine nur im Browser mögliche Abfolge durchlaufen müssen. Interaktive Erweiterungen können anschließend auf dieser zugänglichen Grundlage aufbauen.

Für KI-Übersichten zählt die Suchberechtigung, nicht eine Vorliebe für statische Websites#

Googles Leitfaden zu KI-Funktionen erläutert, dass Seiten indexiert sein und für die Anzeige mit einem Snippet infrage kommen müssen, um als unterstützende Links in KI-Übersichten oder im KI-Modus berücksichtigt zu werden. Die Berechtigung garantiert keine Auswahl.

Eine Website wird nicht allein deshalb bevorzugt, weil ihre Dateien statisch generiert wurden. Auch eine dynamische Seite mit klaren, zugänglichen Inhalten kann infrage kommen.

Google verlangt für diese Funktionen auch weder ein spezielles KI-Schema noch eine zusätzliche KI-Textdatei. Konzentrieren Sie sich zunächst auf nützliche Inhalte, Crawlbarkeit, interne Links und geeignete Einstellungen für die Suche, bevor Sie ein neues Dateiformat als Optimierungsstrategie betrachten.

LLM-Zitate und Markennennungen sind unterschiedliche Ergebnisse#

Wenn ein KI-Assistent während einer Suche eine Seite abruft, unterscheidet sich das davon, dass ein Sprachmodell eine Marke aufgrund zuvor erlernter Informationen erwähnt. Produkte können Suchindizes, den Abruf aktueller Inhalte und Modellwissen auf unterschiedliche Weise kombinieren.

Eine Seite zugänglich zu machen, gibt Abrufsystemen die Möglichkeit, sie zu nutzen. Es ist jedoch nicht garantiert, dass die Seite als Beleg ausgewählt wird, ein Zitat erscheint oder die Marke in einer bestimmten Antwort erwähnt wird.

Berücksichtigen Sie bei der Redaktionsplanung technische Zugänglichkeit und inhaltlichen Nutzen als getrennte Prüfpunkte:

• Zugänglichkeit: Kann das System die relevanten Informationen erreichen und lesen?
• Nutzen: Enthält die Seite eine konkrete, glaubwürdige Antwort auf die gestellte Frage?

Eine Änderung der Darstellungsmethode kann vage Leistungsbeschreibungen, fehlende Produktdetails oder widersprüchliche Informationen auf verschiedenen Seiten nicht ausgleichen.

Öffentliche Informationen auffindbar machen und private Informationen schützen#

Private Dashboards und Kontodaten sollten geschützt bleiben. Sie müssen nicht indexierbar sein, um die Sichtbarkeit des Unternehmens zu verbessern.

Veröffentlichen Sie stattdessen klare öffentliche Seiten, auf denen Ihre Produkte, Dienstleistungen, Preisgestaltung und relevanten Kompetenzen erläutert werden. Geben Sie diesen Seiten stabile Adressen und Navigationslinks, damit sie unabhängig von der Anwendung auffindbar sind.

Bei einer Kursplattform kann die öffentliche Kursbeschreibung den Lehrplan, das Niveau und die Anmeldevoraussetzungen erläutern. Der Lernfortschritt und der Zahlungsverlauf der Lernenden gehören hinter eine Authentifizierungsschranke.

Eine praktische Checkliste für die Architektur#

Vor einem Plattformwechsel oder einer Änderung der Darstellung:

• Prüfen Sie den für repräsentative öffentliche Seiten zurückgegebenen HTML-Code.
• Vergleichen Sie ihn mit der gerenderten Seite, um fehlende Hauptinhalte zu erkennen.
• Stellen Sie sicher, dass wichtige Seiten über eigene, zugängliche URLs verfügen.
• Verwenden Sie für die öffentliche Navigation gewöhnliche, crawlbare Links.
• Überprüfen Sie robots-Regeln, Indexierungsanweisungen, kanonische URLs und HTTP-Statuscodes.
• Testen Sie Inhaltsänderungen, um festzustellen, wann die veröffentlichten Inhalte tatsächlich aktualisiert werden.
• Überwachen Sie die Indexierung und die Seitenerfahrung, statt anzunehmen, dass die Architektur Ergebnisse garantiert.

Weitere Details zur Umsetzung findest du in unserem Leitfaden zu SEO für statische Websites. Dieselbe allgemeine Anforderung gilt für dynamische Seiten: Die Inhalte, die gefunden werden sollen, müssen zugänglich, verständlich und nützlich sein.

Beispiele für Website-Baukästen, CMS und Frameworks#

Tools lassen sich nicht immer eindeutig einer statischen oder dynamischen Kategorie zuordnen. Manche erzeugen Dateien, manche führen Anwendungen aus und manche stellen Inhalte für ein separates Frontend bereit.

Die folgende Tabelle unterscheidet diese Funktionen. Sie umfasst Website-Baukästen, Publishing-Systeme, Generatoren für statische Websites und Frameworks. Vergleiche daher sowohl die Ausgabe als auch den erforderlichen Implementierungsaufwand.

Ein Headless-CMS bestimmt nicht von selbst die Architektur der öffentlichen Website. Dieselbe Content-API kann sowohl einen statischen Build als auch eine serverseitig gerenderte Anwendung versorgen.

Ebenso bedeutet das Vorhandensein eines CMS nicht, dass bei jedem Besuch eine neue Datenbankabfrage ausgelöst wird. Generierte Seiten und zwischengespeicherte Antworten können zwischen dem Content-System und den Besuchern liegen.

Wenn vorgefertigte Ausgaben zu Ihrem Projekt passen, bietet unser Vergleich beliebter Generatoren für statische Websites weitere Optionen. Wenn visuelle Bearbeitung für Sie im Vordergrund steht, sollten Sie den Veröffentlichungsprozess zusammen mit der Ausgabe bewerten, statt nur nach der Bezeichnung der Technologie zu entscheiden.

So unterstützt TeleportHQ statische und dynamische Websites#

Wir unterstützen Projekte, die öffentliche Informationen präsentieren, ebenso wie Projekte, die Daten abrufen und Anwendungsfunktionen ausführen. Sie können die visuelle Benutzeroberfläche erstellen und anschließend die Daten- und Serverfunktionen auswählen, die Ihr Projekt benötigt.

Der Unterschied ist wichtig, wenn Sie Hosting, Codeexport und spätere Änderungen planen. Auch unsere Produktkategorien haben eine konkrete Bedeutung: Eine TeleportHQ-Website kann verbundene Daten anzeigen, ohne dadurch automatisch zu einer TeleportHQ-Web-App zu werden.

Statische Seiten mit Interaktionen im Browser erstellen#

Erstellen Sie mit unserem Baukasten für statische Websites öffentliche Seiten mit wiederverwendbaren Layouts und Komponenten – ganz visuell. Statische Ausgaben können Interaktionen im Browser enthalten. Das Öffnen eines Akkordeons oder der Wechsel zwischen Tabs erfordert nicht grundsätzlich Anwendungsfunktionen auf einem Server.

Eine Service-Website kann beispielsweise ein interaktives Navigationsmenü, eine Erläuterung der Preise und aufklappbare Antworten enthalten und dennoch gemeinsame öffentliche Inhalte präsentieren. Die Interaktion allein macht die Seite nicht zu einer datenbankgesteuerten Anwendung.

Einige Funktionen hängen vom gewählten Exportformat ab. Unser Leitfaden zu Komponentenstatus erklärt, wie einfache, durch Klicks ausgelöste Zustände funktionieren und wo heruntergeladenes HTML an seine Grenzen stößt.

Verbinden Sie Ihre bevorzugte Datenbank oder eine externe API#

Mit unseren Integrationen für Datenquellen können Sie vorhandene Informationen in Ihr Projekt übernehmen. Zu den unterstützten Optionen zählen PostgreSQL, MySQL, MariaDB, MongoDB, Firestore, Supabase und weitere Datenbankdienste.

Sie können eine Datenbank verbinden und dabei die unterstützte Verbindungsmethode verwenden. Für ein System ohne passenden nativen Connector kann eine REST-API, die JSON zurückgibt eine weitere Möglichkeit bieten, sofern der Dienst die benötigten Daten und den erforderlichen Zugriff bereitstellt.

So können Sie Ihre bevorzugte Datenbank flexibel nutzen, ohne davon auszugehen, dass für jede Datenbank-Engine eine native Integration verfügbar ist. Die Verbindungsanforderungen und Funktionen hängen von der jeweiligen Datenquelle ab.

Für redaktionelle Inhalte verbindet unsere Headless-CMS-Integration Ihr Frontend mit einem bestehenden Content-System. Unterstützte CMS-Verbindungen umfassen Strapi, Contentful, WordPress, caisy.io und Flotiq. Der CMS-Einrichtungsleitfaden erläutert den Verbindungsvorgang.

Eine von TeleportHQ bereitgestellte Datenbank verwenden#

Wenn Sie noch keine Datenbank haben, können wir für Ihr Projekt eine gehostete PostgreSQL-Datenbank bereitstellen. Sie können Tabellen erstellen und Datensätze im Editor verwalten, ohne selbst einen separaten Datenbankserver einrichten zu müssen.

Die integrierte Datenbankeinrichtung bietet Ihnen einen Speicherort für strukturierte Informationen wie Produkte oder Mitglieder. Veröffentlichte Seiten können aktualisierte Datensätze abrufen, ohne dass Sie bei jeder Inhaltsänderung erneut veröffentlichen müssen.

Diese Datenbank funktioniert mit dem Hosting von TeleportHQ. Heruntergeladener Code kann sie nicht weiter verwenden, wenn er auf einem anderen Host bereitgestellt wird. Wenn Sie unabhängig hosten möchten, wählen Sie eine externe Datenbank und prüfen Sie die weiteren Exportanforderungen des Projekts, bevor Sie Ihre Lösung auf der gehosteten Option aufbauen.

Kapazität und Verfügbarkeit während des Testzeitraums hängen vom Tarif ab. Die aktuellen Datenbanklimits sind separat dokumentiert.

Daten in Übersichts- und Detailseiten umwandeln#

Eine Datenquelle einzubinden, ist nur der erste Schritt. Anschließend ordnest du ihre Werte den Elementen der Benutzeroberfläche zu.

Eine Kursdatenbank kann zum Beispiel Folgendes bereitstellen:

• Einen Titel und ein Titelbild für jede Kurskarte.
• Eine wiederholte Liste der verfügbaren Kurse.
• Eine Detailseite für einen einzelnen Kurs.
• Strukturierte Zeilen in einer Tabelle.

In unserem Leitfaden zur Datenbindung erfährst du, wie du Felder verbindest und Designs für Datensätze wiederholst. So kannst du die zugrunde liegenden Informationen getrennt vom Layout pflegen, in dem sie angezeigt werden.

Serverseitiges Rendering, Web-Apps und Export verstehen#

Wenn du erstmals eine Datenquelle hinzufügst, verwenden datengesteuerte Seiten serverseitiges Rendering und der Codeexport ist auf Next.js beschränkt. Dadurch wird die separate Kategorie „Web-App“ nicht automatisch aktiviert.

Funktionen wie Benutzerauthentifizierung, Workflows, ein Onlineshop oder der integrierte Blog aktivieren die Web-App-Funktionalität. TeleportHQ-Web-Apps werden auf unserem Hosting betrieben, können nicht als Code heruntergeladen werden und benötigen nach dem anfänglichen Zugriff von sieben Tagen einen Web-App-Slot.

Lies dir durch, woran du ein TeleportHQ-Projekt als Web-App erkennst , wenn du diese Funktionen planst. So kannst du browserbasierte Interaktionen und verknüpfte Inhalte von serverseitigen Vorgängen unterscheiden, die die Anforderungen an die Bereitstellung deines Projekts verändern.

Welchen Ansatz solltest du wählen?#

Der wichtigste Punkt, den du vor der Entscheidung zwischen statischen und dynamischen Websites klären solltest, ist der Zweck deiner zukünftigen Website.

Beginne mit den Aufgaben der Besucher und entscheide anschließend, wie die einzelnen Bereiche funktionieren sollen. Seitenanzahl und visuelle Komplexität sind als Ausgangspunkte weniger hilfreich als Aktualität der Inhalte, Zugriffsanforderungen und die Frage, was Besucher speichern oder ändern können müssen.

Wähle die statische Bereitstellung für öffentliche Inhalte, die im Voraus vorbereitet werden können#

Das eignet sich häufig für:

• Unternehmens- und Dienstleistungsseiten.
• Kampagnen-Landingpages.
• Portfolios und Fallstudien.
• Dokumentation und informative Artikel.
• Katalogbeschreibungen, die nicht für jeden Besucher individuell erstellt werden müssen.

Wählen Sie einen Redaktionsworkflow, der zu Ihrem Team passt. Eine CMS-gestützte Website ermöglicht regelmäßige Veröffentlichungen, während Vorlagen für statische Websites als Ausgangspunkt für gängige öffentliche Seiten dienen können.

Fügen Sie dynamische Funktionen hinzu, wenn die Aufgabe sie erfordert#

Nutzen Sie Laufzeitdienste für Anforderungen wie:

• Sichere Kundenkonten.
• Individuelle Dashboards.
• Bestellungen, Buchungen und Zahlungen.
• Aktuelle Verfügbarkeit oder sich häufig ändernde Betriebsdaten.
• Gemeinsam genutzte Datensätze, die Besucher erstellen oder aktualisieren.

Entscheiden Sie, welche Informationen sofort verfügbar sein müssen und welche zwischengespeichert werden können. Legen Sie außerdem fest, wer für Berechtigungen, Backups, Fehlerbehandlung und laufende Wartung verantwortlich ist.

Ansätze kombinieren, wenn die Website unterschiedlichen Anforderungen gerecht werden muss#

Ein Unternehmen muss sich nicht für jede Route auf eine einzige Rendering-Methode festlegen. Öffentliche Serviceseiten können vorab erstellt werden, der Katalog kann serverseitig gerendert werden und der Kontobereich kann private Daten nach der Authentifizierung laden.

Beantworten Sie vor der Entscheidung für eine Plattform fünf Fragen:

1. Welche Inhalte können für alle Besucher identisch sein?
2. Welche Informationen müssen zum Zeitpunkt einer Aktion aktuell sein?
3. Welche Vorgänge erfordern eine Authentifizierung oder dauerhafte Speicherung?
4. Wer wird die Website aktualisieren und wie oft?
5. Welche Flexibilität beim Hosting und Export wird das Projekt später benötigen?

Diese Antworten bieten eine verlässlichere Grundlage für die Auswahl als die Annahme, statisch bedeute einfach oder dynamisch sei besser.