Neun Jahre auf GitHub Pages, warum ich endlich zu Cloudflare gewechselt bin

Der eigentliche Grund: Ich möchte die Site ausbauen

GitHub Pages ist ideal für ein kleines, überschaubares Portfolio. Neun Jahre lang hat es mich nicht enttäuscht: Push, fertig, kostenlos. Ich musste mir nie Gedanken machen.

Aber meine Pläne für die Site haben sich geändert. Ich will mehr technische Beiträge schreiben, mehr Buchzusammenfassungen veröffentlichen und irgendwann Produkte anbieten: Kurse, vielleicht Fotodrucke oder Presets als Nebenprojekt. Sobald man über Monetarisierung, Traffic und SEO nachdenkt, sieht die Welt anders aus. Eine github.io-Domain ist keine Marke. Link-Eight lässt sich damit nicht ansatzweise so aufbauen wie mit einer eigenen Domain.

Die entscheidende Frage war also: wo registriere ich eine eigene Domain, und was mache ich damit, sobald ich sie habe?

Einen Domain Registrar auswählen

Nach der Evaluierung von sechs Registraren nach Preis, Bedienbarkeit, DNS-Qualität und Zusatzleistungen ergibt sich folgendes Bild:

Anbieter	Preis	Bedienbarkeit	DNS	Extras	Gesamt
Cloudflare Registrar	★★★★★	★★★★☆	★★★★★	★★★★★	10/10
Porkbun	★★★★★	★★★★★	★★★★☆	★★★★☆	9.8/10
Namecheap	★★★★☆	★★★★★	★★★★☆	★★★★☆	9.2/10
Spaceship	★★★★★	★★★★★	★★★★☆	★★★★☆	9.1/10
Dynadot	★★★★☆	★★★★☆	★★★★☆	★★★★☆	9.0/10
GoDaddy	★★☆☆☆	★★★★☆	★★★☆☆	★★☆☆☆	6.5/10

Porkbun und Spaceship sind wirklich gute Optionen. Cloudflare Registrar hat die Nase vorn, weil es zum Selbstkostenpreis abrechnet (kein Aufschlag, Verlängerung zum gleichen Preis wie das erste Jahr), das DNS erstklassig ist und alles an einem Ort liegt: Domain, DNS und Hosting.

Cloudflare Pages vs GitHub Pages

Ist die Domain erst einmal bei Cloudflare registriert, ist das Einrichten auf Cloudflare Pages trivial. Eine eigene Domain an ein Cloudflare-Pages-Projekt anzuhängen, dauert Minuten und erfordert keine DNS-Konfiguration: die DNS-Einträge werden direkt im selben Dashboard verwaltet.

Hier ist der Vergleich der beiden Hosting-Plattformen:

Feature	GitHub Pages	Cloudflare Pages	Warum es wichtig ist
Global CDN	Gut	Hervorragend	Schnellere Ladezeiten für Besucher außerhalb der USA
HTTPS	Ja	Ja	Erforderlich für SEO und Browser-Vertrauen
Automatische Builds	Via GitHub Actions	Inbegriffen	Deploy bei jedem Push ohne Wartung einer Workflow-Datei
Preview Deployments	Nein	Ja	Änderungen vor dem Merge auf einer Live-URL testen
Analytics	Keine	Inbegriffen	Verstehen woher Traffic kommt ohne Third-Party Script
Bildoptimierung	Nein	Ja	Automatisch korrekt dimensionierte Bilder ausliefern
Edge Functions	Nein	Ja	Serverseitige Logik am CDN Edge ohne separates Backend
Build-Geschwindigkeit	Gut	Schneller	Kürzere Feedback-Schleife beim Deployen
Custom Redirects	Eingeschränkt	Hervorragend	Alte URLs sauber umleiten ohne Codeänderungen
Custom Headers	Nein	Ja (via _headers Datei)	CSP, Cache-Control und andere HTTP-Header pro Route setzen
Sofortige Rollbacks	Nein	Ja	Fehlerhaftes Deploy mit einem Klick aus dem Dashboard rückgängig machen
Privates Repository	Ja (kostenlos)	Ja (kostenlos)	Quellcode bei Bedarf privat halten

Für meine aktuelle Site, eine statische Docusaurus-Seite, sind Preview Deployments (praktisch zum Testen von i18n-Änderungen vor dem Merge) und das Edge-CDN die relevantesten Unterschiede.

Was es kostet

Für einen persönlichen Blog sind Cloudflare Pages, CDN, HTTPS, Deployments und Preview Builds alle kostenlos. Der einzige wirkliche Kostenpunkt ist die Domain-Registrierung selbst, die etwa 11 € pro Jahr kostet, abhängig vom Domain-Namen, über Cloudflare Registrar.

Was sich tatsächlich im Repository geändert hat

Das Erstaunliche: Die Migration erwies sich als überraschend unkompliziert.

Entfernt: .github/workflows/deploy.yml, der GitHub-Actions-Workflow, der die Site gebaut und in den gh-pages-Branch gepusht hat.

Hinzugefügt: wrangler.jsonc, 14 Zeilen:

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "website",
  "compatibility_date": "2026-07-19",
  "observability": {
    "enabled": true,
  },
  "assets": {
    "directory": "build",
  },
  "compatibility_flags": ["nodejs_compat"],
}

Aktualisiert: zwei Scripts in package.json:

"deploy": "yarn run build && wrangler deploy",
"preview": "yarn run build && wrangler dev"

Das war’s. Deployen läuft jetzt per yarn deploy, lokales Vorschauen mit der Cloudflare-Runtime per yarn preview.

Was schiefgelaufen ist

Die Migration selbst ging schnell. Die Probleme, die danach auftauchten, waren weniger offensichtlich, genau die Art von Fallstricken, die in keiner Dokumentation stehen.

Package Manager Erkennung

Cloudflares CI erkennt den Package Manager automatisch anhand der package.json. Fehlt die Festlegung im packageManager-Feld, versucht das System eigenständig zu upgraden oder zu wechseln. Abhilfe schafft explizites Pinnen:

"packageManager": "yarn@1.22.22"

Ohne diese Festlegung versuchte Cloudflares Build-Umgebung, yarn selbstständig zu aktualisieren, mit der Folge, dass der Build brach.

Docusaurus URL Konfiguration

Docusaurus nutzt das url-Feld in docusaurus.config.ts, um absolute URLs für Sitemap, Canonical-Tags, RSS-Feeds und og:image zu generieren. Bei mir war noch die alte GitHub-Pages-Domain eingetragen:

url: "https://ammarnajjar.github.io",

Alles baute und deployte einwandfrei, aber die Sitemap war voller falscher URLs, og:image zeigte ins Leere, und die RSS-Feed-Links waren kaputt. Die Lösung ist simpel: url vor dem Deployen auf die eigene Domain aktualisieren.

url: "https://ammar-najjar.com",

Leicht zu übersehen, denn die Site sieht im Browser korrekt aus, die Fehler bleiben unsichtbar, solange man nicht in den Quelltext schaut oder ein SEO-Audit fährt.

Custom Domain Setup in Cloudflare

Ist die Site erst unter https://<project>.pages.dev live, braucht der eigene Domain-Anschluss nur drei Schritte im Cloudflare-Dashboard:

1. Gehe zu Workers & Pages, öffne dein Projekt, dann Custom domains
2. Füge deine Domain hinzu. Cloudflare erstellt die DNS-Einträge automatisch, da Domain und Pages-Projekt im selben Account liegen
3. Warte ein paar Minuten auf das TLS-Zertifikat; die Domain geht automatisch live

Bei einer extern registrierten Domain müsstest du manuell einen CNAME-Eintrag hinzufügen. Wer über Cloudflare Registrar registriert, spart sich diesen Schritt komplett.

Privates GitHub Repository

Wenn du dein Repository nach der Verbindung mit Cloudflare Pages privat schalten willst, musst du sicherstellen, dass die Cloudflare-GitHub-App Zugriff auf private Repositories hat. Gehe in die GitHub-Einstellungen unter Applications, suche die Cloudflare-Pages-App und prüfe den Zugriff auf das betreffende Repo. Andernfalls schlagen Builds nach dem Umstellen auf privat stillschweigend fehl.

Die Schritte, in Reihenfolge

So gehst du vor, wenn du dasselbe machen möchtest:

1. Erstelle ein Cloudflare Konto
2. Verbinde dein GitHub-Repository und deploye die Site von Cloudflare Pages aus
3. Prüfe, ob sie unter https://<project>.pages.dev läuft
4. Nimm alle Verbesserungen vor, ein guter Moment für ein Site-Audit
5. Kaufe deine eigene Domain über Cloudflare Registrar
6. Hänge die Domain an das Pages-Projekt an (Minutenarbeit, keine manuelle DNS-Konfiguration)
7. Aktiviere Redirects, damit der gesamte Traffic auf deine Domain läuft

Die Reihenfolge ist wichtig: erst deployen, dann kaufen. Du willst sicher sein, dass die Site läuft, bevor du Geld ausgibst, und das Pages-Projekt muss existieren, wenn die Domain zugeschaltet wird.

Alte Links am Leben erhalten

Die alte ammarnajjar.github.io-URL lebt weiter und leitet jetzt auf ammar-najjar.com weiter. Statt auf einen serverseitigen Redirect zu setzen (den GitHub Pages nicht bietet), erledigt die index.tsx der Site das clientseitig: ein meta http-equiv="refresh" für Crawler, ein window.location.replace() für Browser und ein sichtbarer Fallback-Link für den Notfall. Der vollständige Quellcode ist auf GitHub.

Eine Zahl

Es gibt keine Lighthouse-Werte vom alten GitHub-Pages-Setup, mit denen ich vergleichen könnte. Einen Vorher/Nachher-Benchmark würde ich mir also nur ausdenken. Cloudflares Analytics zeigen eine Cache-Hit-Rate von rund 80% für diese Site. Das bedeutet: 8 von 10 Requests werden direkt vom Cloudflare-Edge ausgeliefert, ohne den Origin-Server zu berühren. Für einen statischen Blog mit vielen wiederkehrenden Besuchern ist das die Sorte Zahl, die sich direkt in schnelleren Ladezeiten niederschlägt.

Hat es sich gelohnt?

Ja. Der Deployment-Workflow ist einfacher, Domain und Hosting liegen an einem Ort, und Preview Deployments, Analytics und sofortige Rollbacks kommen ohne zusätzliche Konfiguration daher.

Wer mit GitHub Pages zufrieden ist und keine Ausbaupläne hat, braucht nicht zu wechseln. Wenn du aber ohnehin eine eigene Domain registrierst, ist der Weg über Cloudflare zu Cloudflare Pages der Pfad des geringsten Widerstands. Die Migration hat einen Nachmittag gedauert, und das Ergebnis ist ein Setup, das ich für das nächste Jahrzehnt nicht mehr anfassen will.

Neun Jahre sind eine gute Laufzeit für jedes Tool. GitHub Pages hat seinen Dienst getan. Der Wechsel war keine Abkehr. Es war eine Frage des Anspruchs.

Wenn du heute eine persönliche Site hostest: Würdest du wieder zu GitHub Pages greifen oder gleich mit Cloudflare Pages starten? Mich würde interessieren, welche Erfahrungen andere dabei gemacht haben.