PHP hat einen Static Site Generator

Lange Zeit gab es für PHP keinen Static Site Generator, der mich wirklich überzeugen konnte.

Seitdem es Stenope gibt, hat sich das geändert. Ich möchte diesen feierlichen Anlass nun nutzen, um über die Welt der Static Site Generatoren zu sprechen.

Am Ende dieses Artikels gebe ich dir einen kleinen technischen Einblick, wie ich diesen Blogbeitrag, den du in diesem Moment liest, mit Stenope umgesetzt habe.

Was ist ein Static Site Generator?

Gut, dass du fragst! Ein Static Site Generator erzeugt statisches HTML. Nicht mehr und nicht weniger.

Meist werden dabei Daten, wie z.B. Blogposts, in einem textbasierten Format wie Markdown oder JSON gespeichert und auf Abruf erzeugt.

Das HTML, das dabei entsteht, ist immer statisch – also unveränderlich. Jeder Mensch auf der Welt sieht am Ende exakt genau die gleiche Webseite.

Die Idee ist keineswegs neu. HTML wurde nämlich genau für diesen Zweck entwickelt. Das Netz war in seinen Anfängen eine Ansammlung statischer HTML-Seiten, auf die Menschen weltweit zugreifen konnten.

Bekannte Static Site Generatoren wie z.B. Hugo oder Gatsby gibt es seit langer Zeit und sie werden bevorzugt von tech-affinen Menschen benutzt, die bereit sind, ihre Inhalte im Markdown-Format zu pflegen und per Git zu versionieren.

Auch gibt es mittlerweile Content Management Systeme (CMS), die diesen Ansatz zumindest anbieten (Statamic) oder gar puristisch verfolgen (TinaCMS). Ziel dieser Systeme ist es, die Vorteile von statischem HTML mit denen von Content Management Systemen zu kombinieren. Die Abkürzung für Static Site Generatoren ist SSG.

Welche Vorteile bietet ein Static Site Generator?

Ein Static Site Generator spart Zeit und Geld. Er erhöht die Performance deiner Webseite, weil das statische HTML ohne Zwischenschritt direkt an die Browser deiner Besucher ausgeliefert werden kann. Das statische HTML bietet außerdem viele weitere Vorteile:

• Statisches HTML kann auf einem Content Delivery Network (CDN) leben und benötigt somit keinen eigenen Server.
• Die Auslieferung von statischem HTML kostet dich sehr wenig oder gar nichts.
• Statisches HTML ist sehr sicher – Sicherheitslöcher wie CVE-2026-109618 und CVE-2026-109619 brauchen einen Server, der Code ausführt, und genau den hat deine Seite nicht mehr.
• Statisches HTML ist rasend schnell – weil es sich gut zwischenspeichern lässt (Caching). Sowohl im Browser als auch in einem CDN.
• Statisches HTML selbst kennt keine Systemupdates. Denn es handelt sich einfach nur um Dokumente – nicht um eine komplexe Applikation wie z.B. ein WordPress-System.
• Statisches HTML ist langlebig. Es liegt einfach im Netz und das wird es auch noch in 10 Jahren tun – selbst ohne weiteres Zutun.

Muss ich mein HTML wirklich generieren?

Natürlich benötigst du keinen Static Site Generator, um statisches HTML zu erzeugen. Deine eigene Webseite hast du auch so in 10 Minuten im Internet:

<!DOCTYPE html>
<html lang="de">
    <head>
        <meta charset="utf-8" />
        <title>Kursinstitut Seeblick</title>
    </head>
    <body>
        <h1>Kursinstitut Seeblick</h1>
        <p>
            Erste Hilfe, Brandschutz, Staplerschein. Neue Termine jeden Monat.
        </p>
    </body>
</html>

Lädst du das nun manuell auf ein CDN (Content Delivery Network), ist deine kostenlose, rasend schnelle Webseite sofort weltweit verfügbar.

Okay, schön ist sie nicht. Das bekommen wir aber mit etwas Inline-CSS hin. Du entwickelst einfach lokal auf deinem Laptop und, sobald du mit dem Ergebnis zufrieden bist, lädst du alles noch einmal hoch.

Was ist jedoch, wenn weitere Seiten hinzukommen? Jede Webseite braucht zumindest ein Impressum und eine Datenschutzerklärung.

Jetzt fängt es schon an, komplizierter zu werden. Wenn du nicht möchtest, dass jede Seite anders aussieht, duplizierst du von da an HTML-Strukturen auf jeder einzelnen Seite, um dein Layout konsistent zu halten.

Dann fällt dir ein, dass eine Menüführung eine gute Idee wäre.

Schreibst du weiterhin dein HTML selbst, wird es erforderlich sein, dein Menü auf jede einzelne Seite zu kopieren.

Anpassungen an deinem Menü zwingen dich, in jede einzelne HTML-Datei zu gehen und die immer gleiche Änderung manuell vorzunehmen. Sicher, heutzutage kann eine KI dir dabei behilflich sein, aber selbst dann wird diese Methode schnell zu einem Nährboden für Inkonsistenz und unnötigen Aufwand.

Sagen wir einfach, du bist besonders hartnäckig und empfindest Freude daran, dein HTML selbst zu pflegen. Diese Freude wird dir spätestens dann vergehen, wenn du mehrere Versionen deiner Inhalte anbieten möchtest, wie zum Beispiel JSON-LD-Metadaten oder Markdown-Versionen deiner Seiten.

Nun hast du nicht nur Duplikationen deiner HTML-Strukturen in all deinen HTML-Dateien, sondern auch inhaltliche. Spätestens jetzt wird das Schreiben von einfachem HTML wohl für die meisten Leute uninteressant.

Und genau hier liegt das Einsatzgebiet von Static Site Generatoren.

Schau dir das mal an:

{# @var section App\Content\Section #}
{# @var article App\Content\BlogPost #}
{% trans_default_domain 'website' %}
{% extends "website/base/article.html.twig" %}

{% block title -%}
    {{ 'blog_post.meta_title'|trans({ '%title%': article.title }) }}
{%- endblock %}

{% block meta -%}
    {% include 'website/partials/_meta.html.twig' with {
        page_title: block('title')|trim,
        page_description: article.description,
        og_type: 'article',
        markdown_url: markdown_url,
    } only %}

    {% include 'website/blog/_article_meta.html.twig' with {
        article: article,
        section: section.title,
    } only %}
{%- endblock %}

{% block main_foot -%}
    {% include 'website/blog/_citations.html.twig' with {
        citations: article.citations,
        references: article.citationReferences,
    } only %}
{%- endblock %}

Was du hier siehst, ist das Twig-Template für diesen Blogbeitrag, den du gerade liest. Dieses knappe Template reicht außerdem aus, um alle Blogbeiträge in allen Sprachen zu generieren – nicht nur diesen hier auf Deutsch.

Auch einzelne Teile (sogenannte Partials) sind wiederverwendbar. Wie du siehst, gibt es eine Vererbungsstruktur mit der Möglichkeit, einzelne Blöcke des Elterntemplates zu überschreiben. Andere Abschnitte wiederum werden bei Bedarf einfach inkludiert.

Somit bleibt alles gut lesbar, konsistent und wiederverwendbar. Das verbessert die Wartbarkeit und verringert die Kosten für Änderungen enorm – steigert also die Erweiterbarkeit.

Ist ein Static Site Generator für meine Webseite geeignet?

Nehmen wir an, du hast eine Unternehmenswebseite, die mit WordPress läuft. Du hast die Zugangsdaten für deinen Adminbereich erhalten und kannst von dort aus deine Inhalte pflegen.

Nur gibt es dabei einen Haken. Ahnst du es schon? Ein Problem, dessen du dir vielleicht gar nicht bewusst bist. Pflegst du wirklich deine Inhalte? Du könntest es jederzeit tun – machst es aber kaum oder gar nicht (mehr).

Das soll absolut kein Vorwurf sein. Deine Webseite ist schließlich fertig. Die Welt dreht sich seitdem weiter.

Das Problem ist nun, dass du eine komplexe Applikation im Internet betreiben lässt, deren Hauptzweck darin besteht, Inhalte zu pflegen, ohne jemanden beauftragen zu müssen. Und genau das hat paradoxerweise dafür gesorgt, dass du in eine teure Abhängigkeit zu deiner Agentur geraten bist. Kommt dir das bekannt vor?

Es gibt Studien, die belegen, dass du mit dieser Situation nicht alleine dastehst.

Zum Beispiel hat SIINDA, der europäische Branchenverband für lokale Suche, in acht europäischen Ländern die Online-Präsenz von über 350.000 KMU untersucht. 46 Prozent der Webseiten wurden laut der Landscape Study 2019 binnen eines Jahres kein einziges Mal aktualisiert.

Selbst Seiten, die auf Seite eins bei Google stehen, werden laut einer Analyse im Schnitt nur alle zwei Jahre aktualisiert.

Stellen wir uns also vor, deine Firma möchte jedes Jahr ein einziges Mal etwas verändern – z.B. ein neues Teamfoto hochladen oder einen Blogpost über eine Unternehmensauszeichnung veröffentlichen. Dann ist ein Static Site Generator perfekt geeignet. Deine Inhalte sind statisch – also ist statisches HTML die ehrlichste und effizienteste Lösung für dich und dein Unternehmen.

An den folgenden Punkten erkennst du, dass eine statische HTML-Webseite für dein Unternehmen besser geeignet ist als ein Content Management System.

• Du loggst dich kaum in dein System ein und vergisst sogar deine Anmeldedaten regelmäßig.
• Dein CMS ist dir zu kompliziert, sodass du deine Agentur sogar für Änderungen anrufst, die das CMS dir eigentlich ermöglichen sollte.
• Dein System ist dir zu teuer und du fragst dich, warum eine simple Firmenwebseite jährlich so viele Kosten verursacht.
• Dein System ist dir zu langsam. Du hast vielleicht sogar schon einen Serverwechsel hinter dir und ein Performance-Plugin installiert und trotzdem bleibt deine Webseite langsam.
• Du möchtest keine Systemupdates mehr. Alle paar Jahre läuft dein CMS aus dem Support, und die Migration kostet fast so viel wie ein Neubau – für im Grunde statisches HTML.
• Du möchtest ein gutes Gefühl haben. Vielleicht warst du schon einmal Ziel eines Angriffs und willst nie wieder fürchten, dass deine Firmenwebseite zur Werbefläche für fremden Schund wird.

Warum empfiehlt mir niemand einen Static Site Generator?

Wenn du schon einmal mit einer Agentur gearbeitet hast, die auf ein Content Management System setzt, ahnst du vielleicht schon, warum dort ein anderes Lied gesungen wird. Dort möchte man von Static Site Generatoren nichts hören. Dort wird stattdessen betont, wie komfortabel du mit dem CMS deine Webseiten pflegen kannst. Man zeigt dir glänzende Dashboards mit grenzenlosen Möglichkeiten und tollen Plugins.

Dass sich dadurch teure Wartungsverträge, Upgrades auf neuere Versionen, Relaunches und Optimierungen verkaufen lassen, ist kein Zufall, sondern der Kern des Geschäftsmodells.

Außerdem ist da der Wunsch nach einem Allzweckwerkzeug. Agenturen wünschen sich ein Tool, mit dem sie einfache Webseiten und komplexe Systeme gleichermaßen umsetzen können. Somit wird das CMS schnell für alles Mögliche benutzt und zum heiligen Gral erklärt.

Auch als Verkaufsargument und Vertrauensanker benutzt man das CMS gerne. Das CMS ist im Grunde der Kern der Agentur und ein CMS lebt von den zahlreichen Agenturen, die es vertreiben.

Aber würdest du dir einen LKW zulegen, ihn pflegen, warten und die Betriebskosten zahlen, damit du ihn alle 1–2 Jahre für den nächsten Umzug aus dem eigens dafür errichteten Fahrzeugschuppen holen kannst?

Es stimmt zwar, du kannst damit alles transportieren. Von der winzigen Umhängetasche bis zur LKW-Ladung voller Blumenerde. Wäre das nicht absurd? Ja, das wäre es.

Eine Web-Applikation im Internet zu betreiben, sie alle 1–2 Jahre aufzusuchen und dort ein kleines Stück deiner statischen Inhalte zu ändern – ist in der Tat ähnlich verschwenderisch.

Wie viel kann statisches HTML einsparen?

Ohne statisches HTML benötigst du einen laufenden Webserver mit einer Programmiersprache wie PHP und einer Datenbank. Jede Minute, in der dieses System nicht mit Strom versorgt wird, ist deine Webseite weg. Puff. Geschichte. Dein System muss also bereitstehen, rund um die Uhr. Auch nachts um drei.

Mich hat interessiert, was dabei an Kosten für Strom und Hosting zusammenkommt.

Ein Hetzner EX44 – das Einstiegsmodell – zieht im Leerlauf 25 Watt und unter Volllast 118.¹ Trägt er ein WordPress mit wenig Besuch, sind das über ein Jahr rund 350 Kilowattstunden. Er kostet 44 Euro im Monat, also 528 Euro im Jahr (Stand: Oktober 2026).

Sicher, es gibt günstigere Arten, deine Unternehmensseite zu hosten – du kannst jedoch auch weitaus mehr bezahlen. Ich denke, wir haben mit diesem Hetzner Einstiegsmodell einen guten Mittelweg für unsere Beispielrechnung gefunden.

Du fragst dich jetzt sicher, was sich von diesen 528 Euro einsparen ließe. Die Antwort ist: So gut wie alles!

Diese Webseite hier kostet mich im Hosting nichts. Cloudflare, ein weltweites Netz von Rechenzentren, liefert statische Dateien unbegrenzt aus² – egal wie viele Daten, egal wie oft sie jemand abruft. Selbst ein riesiges Projekt mit 100.000 Seiten kostet nur rund fünf Euro im Monat – ganz egal, wie viel auf deiner Webseite los ist.

Natürlich laufen auch bei Cloudflare Server. Nur laufen sie nicht für deine Webseite allein. Und ein einzelner Aufruf kostet so wenig, dass mehrere Milliarden Aufrufe deiner Webseite notwendig wären, um auf den Stromverbrauch für ein Jahr Bereitschaft unseres Hetzner EX44 Servers zu kommen.¹³

Das liegt daran, dass beim Ausliefern einer fertigen Datei fast nichts zu rechnen ist. Es startet kein PHP, es wird keine Datenbank befragt, es wird kein HTML zusammengebaut. Die fertige Datei liegt einfach da und wird durchgereicht.

Die Maschinen in diesen Rechenzentren sind dabei alles andere als klein. Nur bedient jede davon zehntausende Aufrufe in der Sekunde – eben weil ein einzelner Aufruf so wenig kostet.

Im Netz sind nach Zählung von Netcraft rund 216 Millionen Webseiten aktiv.⁴ Wie wir weiter oben erfahren haben, wurden 46 Prozent der untersuchten Webseiten binnen eines Jahres kein einziges Mal aktualisiert.

Wenn wir nun ganz vorsichtig annehmen, es seien nur acht Millionen Webseiten weltweit, die statisch sein könnten, jedoch dynamisch betrieben werden, kommen wir auf ein gigantisches jährliches Einsparungspotential.

2.800 Gigawattstunden sind fast so viel Strom, wie ganz Malta in einem Jahr verbraucht.⁵

Dabei ist das Hosting in den meisten Fällen noch der kleinste Posten. Die wahren Kostentreiber eines CMS sind Wartungsverträge, Sicherheitspatches, aufwendige Migrationen bei jedem großen Update und allem voran die Entwicklungsgeschwindigkeit, die stetig sinkt, bis der nächste Relaunch notwendig wird.

Macht statisches HTML abhängig von einer Agentur?

Wenn du deine Inhalte nicht selbst in Markdown bearbeiten und dich nicht mit Git-Versionierung beschäftigen möchtest, wirst du für deine Änderungen höchstwahrscheinlich die Hilfe eines Technikers benötigen.

In diesem Fall zahlst du jedoch ausschließlich für die Änderungen und nicht für die laufenden Kosten eines komplexen Systems. Mit anderen Worten zahlst du nur für ehrliche Arbeit und echte Wertschöpfung.

Meine Kunden erhalten auf Wunsch mittlerweile einen MCP-Zugang zu ihrer Webseite. Damit kann dein KI-Chatbot die Inhalte deiner Webseite verwalten – inklusive Vorschaulinks mit optionalem Passwortschutz. Wenn dich das interessiert, melde dich einfach bei mir. Dann zeige ich dir, was ich damit meine.

Die Grenzen von statischem HTML

Statisches HTML ist super cool für Millionen von Unternehmens- und Portfolio-Seiten, aber natürlich hat es ein begrenztes und klar abgegrenztes Einsatzgebiet.

Dynamische Inhalte

Wie der Name schon andeutet, ist statisches HTML von Natur aus nicht dynamisch. Jede Seite muss im Vorhinein gerendert werden.

Das fällt besonders auf, sobald viele verschiedene Kombinationen der gleichen Seite möglich sind – wie bei dieser Kursübersicht.

Niemand kann wirklich wissen, in welcher Kombination der Besucher nach Kategorien, Veranstaltungsorten oder Preisen filtern und sortieren wird.

Das lässt sich zwar mit JavaScript und Tricks wie versteckten Daten, eingebettet in unsichtbare HTML-Tags, lösen. Unschön und etwas hacky bleibt es jedoch trotzdem. SEO-freundlich ist es auch nicht.

Also bleibt für solche Sachen eine einfache Web-Applikation die passende Wahl. Und ich meine damit bewusst kein CMS – nur weil deine Webseite ein zentrales dynamisches Element besitzt, benötigt sie noch lange kein WordPress.

Inhalte mit Ablaufdatum

Eine Jahreszahl wie in „© 2026 Braunstetter“ zeigt in statischem HTML auch noch das Jahr 2026, wenn schon längst das Jahr 2046 angebrochen ist.

Das Gleiche gilt übrigens für die oben erwähnte Kursübersicht. Reines statisches HTML würde in zwanzig Jahren hoffnungslos veraltete Kurse anzeigen.

Auch dieses Problem lässt sich lösen. Es gibt beispielsweise die Möglichkeit, eine Scheduled pipeline zu erstellen. Die ermöglicht es dir, in regelmäßigen Abständen deine statische Webseite neu zu rendern und somit auch deine Daten aktuell zu halten.

Du denkst dir jetzt vielleicht: Wenn meine Webseite auf einen regelmäßigen Rebuild angewiesen ist, bin ich wieder abhängig von einem System, das auch in Jahren noch lauffähig sein muss.

Das stimmt natürlich. Aber dieses System ist viel kleiner als ein CMS und du zahlst diesen Preis bewusst und gezielt für etwas, das du wirklich brauchst. Ein guter Entwickler wird einen Static Site Generator wählen, der deine Webseiten auch in Jahren noch zuverlässig rendert.

Außerdem bleibt HTML, das schon im Netz liegt, von diesen Dingen unbeeindruckt. Im schlimmsten Fall würden deine Inhalte schlicht und einfach nicht weiter aktualisiert werden. Eine CMS-Webseite, deren Server ein Problem hat, würde auf einmal anfangen, unschöne Abstürze zu produzieren, langsamer zu werden oder Schlimmeres.

Geschützte Bereiche

Statisches HTML ist für viele Webseiten ein wahrer Segen. Wenn du jedoch einen Bereich möchtest, in dem du dir z.B. alle deine Kurse ansehen kannst wie hier, dann ist statisches HTML leider keine Option. Für solch einen Adminbereich benötigst du in jedem Fall eine Web-Applikation.

Allerdings ist es durchaus möglich, deine statische Webseite ohne einen Adminbereich durch einen MCP-Zugang zu bedienen. Du kannst beispielsweise einfach deinen KI-Agenten anweisen: „Zeige mir meine letzten 5 Blogbeiträge.“ Anschließend kannst du mit deiner KI gemeinsam an einem bestimmten Beitrag arbeiten und ihn veröffentlichen, sobald du zufrieden bist.

Neugierig geworden? Dann melde dich doch bei mir und lass uns drüber sprechen.

Formulare

Ohne ein laufendes System ist es deiner Webseite schlichtweg unmöglich, Formularanfragen entgegenzunehmen. Es ist zwar sehr wohl möglich, Formulare anzuzeigen, aber statisches HTML kann keinerlei Anfragen verarbeiten. Wie auch? Das sind nur Dokumente, die im Internet liegen.

Die gute Nachricht ist: Die meisten Webseiten benötigen keine Formulare. Das klassische Kontaktformular schreckt viele Nutzer nur ab. Oder füllst du gerne solche Formulare aus?

Im schlimmsten Fall wird dein Kontaktformular, wenn es schlecht umgesetzt ist, ein Magnet für allerlei nervigen Spam.

Viel angenehmer ist dagegen ein mailto-Link. Damit kannst du den Leuten sogar die Mail an dich vorformulieren. Klick hier – dann siehst du es live. Ich würde mich sehr über eine Mail von dir freuen.

Sollte deine statische Webseite jedoch wirklich einmal ein Formular benötigen, geht das über Serverless Functions. Cloudflare bietet dazu Cloudflare Pages Functions. Damit kann man z.B. Kondolenzbekundungen, Anfragen oder Anmeldungen recht bequem abbilden.

Eine Webseite, die viel mit Formularen arbeitet, sollte allerdings als Web-Applikation und nicht als statische Webseite umgesetzt werden.

Stenope

Anfangs habe ich versprochen, dir zu zeigen, wie ich diesen Blogbeitrag mit Stenope gerendert habe. Aber lass mich vorher noch ein paar wichtige Dinge ins rechte Licht rücken.

Was ist Stenope?

Streng genommen handelt es sich bei Stenope nicht einmal um einen Static Site Generator, sondern um ein Symfony-Bundle. Stenope ist somit lediglich eine Erweiterung für das beliebte Symfony-Framework.

Warum Stenope?

Für viele Entwickler ist Hugo, Gatsby oder Next.js sicher die bessere Wahl. Für mich als Symfony-Entwickler bietet Stenope allerdings einen riesigen Vorteil – den Upgradepfad.

Stell dir vor, dir genügt anfangs eine statische Unternehmenswebseite. Mit der Zeit steigen jedoch deine Ansprüche. Du wünschst dir vielleicht eine Kundenverwaltung, eine Mitarbeiterplattform oder einen Produktkatalog.

Würde ich solche Projekte mit Hugo beginnen, müsste ich sie aufwendig von Hugo/Go nach Symfony/PHP migrieren und ich würde dabei Tage oder sogar Wochen nur damit verbringen, den Status quo wiederherzustellen.

Mit Stenope gestaltet sich der Übergang von der statischen Webseite zur Web-Applikation vergleichsweise leicht. Im Prinzip kann nämlich alles bleiben, wie es ist. Hinzu kommen lediglich die neue Infrastruktur wie Webserver und Datenbank – und natürlich die Logik deiner neuen Unternehmenssoftware.

Stenope in der Praxis

Software spricht immer nur eine Muttersprache: Code.

Dabei kannst du dir Maschinencode und Assembly als Laute, Silben und einzelne Wörter vorstellen. Hochsprachen wie Java, PHP oder Ruby ermöglichen es uns zu guter Letzt, ganze Sätze zu formulieren und damit sinnvolle Texte zu produzieren.

Ein Projekt wie diese Webseite stelle ich mir gerne als Buch vor. Ich möchte dir heute das kurze Kapitel aus diesem Buch zeigen, das diesen Blogbeitrag rendert, den du gerade vor Augen hast.

// src/Controller/BlogPostController.php
final class BlogPostController extends AbstractController
{
    public function __construct(
        private readonly SectionRepository $sectionRepository,
        private readonly PageGraphBuilder $pageGraphBuilder,
        private readonly Trail $trail,
        private readonly MarkdownDocumentBuilder $markdownDocuments,
    ) {
    }

    #[ContentCollectionRoute('/{_locale}/blog/{slug}/')]
    public function __invoke(BlogPost $entry, Request $request): Response
    {
        if ($request->getRequestFormat() === 'md') {
            return $this->markdownDocuments->forBlogPost($entry);
        }

        return $this->render('website/blog/show.html.twig', [
            'section' => $this->sectionRepository->find(SiteSection::Blog),
            'article' => $entry,
            'parents' => $this->trail->to($entry),
            'markdown_url' => $this->generateUrl(
                route: ContentRouteName::forMarkdownRoute($request->attributes->getString('_route')),
                referenceType: UrlGeneratorInterface::ABSOLUTE_URL,
            ),
            'json_ld_graph' => $this->pageGraphBuilder->forBlogPost($entry),
        ]);
    }
}

Eine Datei, eine Seite

Gehen wir es kurz gemeinsam durch.

Der gesamte BlogPostController ist ein ganz normaler Symfony-Controller mit einer einzigen Controller-Action.

Das Besondere daran ist das PHP-Attribut ContentCollectionRoute. Es registriert für jeden Blogbeitrag, der als Markdown-Datei unter content/blog/de/ liegt, eine eigene Route, die anschließend von Stenope als statisches HTML gerendert werden kann.

Sobald ich einen neuen Blogbeitrag hinzufügen möchte, lege ich einfach eine neue Datei an und beginne zu schreiben. Symfony und Stenope erkennen den neuen Blogbeitrag automatisch.

Ist das nicht fein?

Markdown und JSON-LD

Wie du siehst, gibt es sogar eine Markdown-Version dieses Blogbeitrags. KI-Agenten können daraus viel schneller und mit deutlich weniger Tokens die wichtigen Informationen extrahieren.

Auch an JSON-LD wurde natürlich gedacht. Das sind strukturierte Daten, die es dir ermöglichen, Inhalte im Netz mit einem bekannten Vokabular zu klassifizieren.

Dieser Beitrag wurde zum Beispiel als WebPage ausgezeichnet, deren Hauptgegenstand ein BlogPosting ist. Dazu trägt die Seite eine BreadcrumbList, die mit ihr selbst endet.

Raus kommt statisches HTML

Die Controller-Action BlogPostController::__invoke rendert zum Schluss ein Template.

Das geschieht natürlich nicht durch Magie – aber in gewisser Weise „auf Knopfdruck“. Es genügt ein einziger Befehl im Terminal:

bin/console stenope:build ./static

Et voilà – fertig ist die statische Webseite mit Stenope. Sie liegt nun im Ordner static deines Projektes.

Wenn du noch mehr erfahren möchtest – zum Beispiel, wie du das Ganze ins Internet bekommst –, gebe ich dir gerne weitere Einblicke. Schreib mir einfach auf dem Kanal deiner Wahl. Ich zeige dir alles – versprochen.

Ich hoffe, dir hat dieser Artikel gefallen. Vielleicht konnte ich dich ja sogar von den Vorzügen von statischem HTML überzeugen.

Wenn du noch Fragen oder Anmerkungen hast, lass es mich wissen. Den Weg zu meiner Kontaktseite findest du ja mittlerweile.

Überlegst du schon, ob deine Webseite vielleicht statisch werden soll?