Astro + Cloudflare Pages: Vollständige Launch-Checkliste

Eine Astro-Site auf Cloudflare Pages zu deployen geht schnell. Die Build-Pipeline verbindet sich in Minuten mit GitHub und deployed automatisch bei jedem Push. Was Zeit kostet, ist alles drumherum: SEO-Korrektheit, Security Headers, DSGVO-Konformität, strukturierte Daten, DNS-Konfiguration und das Monitoring der ersten Woche, das zeigt, ob etwas nicht stimmt.

Diese Checkliste pflegen wir über alle unsere Astro + Cloudflare Pages-Projekte hinweg. Sie ist der Unterschied zwischen einer Site, die live ist, und einer Site, die tatsächlich bereit ist.

Vor dem ersten Code — Handles sichern

Bevor die Entwicklung beginnt, die wichtigen Markennamen registrieren. Diese werden schnell vergeben, und die Rückgewinnung eines bereits genutzten Handles ist entweder unmöglich oder teuer.

GitHub-Org oder Nutzerprofil mit Repository
LinkedIn-Unternehmensseite (für Agentur- und Produktmarken)
Twitter/X-Handle
Instagram-Handle (für Produkt- und Visualmarken)

Die primäre Domain registrieren und DNS sofort zu Cloudflare übertragen. Bei bekannten Schreibvarianten (ohne Bindestrich, .dev, .io) lohnt sich die Registrierung von Weiterleitungsdomains.

Technische SEO

Jede Seite braucht einen eindeutigen <title> (50–60 Zeichen) und eine eindeutige <meta name="description"> (150–160 Zeichen). Das ist keine Option — Google nutzt sie direkt in den SERPs, und doppelte Titles sind ein negatives Coverage-Signal.

Canonical URLs benötigen in Astro-SSG-Builds einen Trailing-Slash-Guard. Astro.url.pathname verliert den Trailing Slash beim Build, selbst wenn trailingSlash: 'always' gesetzt ist. Das produziert falsche Canonicals auf jeder Seite und verursacht 308-Redirect-Ketten:

const _pathname = Astro.url.pathname.endsWith('/')
  ? Astro.url.pathname
  : Astro.url.pathname + '/';
const canonicalURL = new URL(_pathname, Astro.site);

OG- und Twitter-Card-Tags: og:title, og:description, og:image, og:url, og:type sowie die Twitter-Entsprechungen. Das OG-Bild muss 1200×675px WebP oder PNG sein — niemals SVG. Social-Scraper ignorieren SVG-Dateien lautlos und zeigen keine Vorschau an.

max-image-preview:large im Robots-Meta-Tag setzen. Das ist Voraussetzung für Google Discover — ohne diese Angabe erscheinen Bilder dort nicht in voller Größe.

Bei bilingualen Sites hreflang-Tags setzen. Jede Sprachversion sollte auf die andere verweisen.

JSON-LD Structured Data

Schema-Markup erzeugt Rich Snippets in den Suchergebnissen und hilft Google zu verstehen, worum es auf einer Seite geht. Standardmäßig fügen wir folgende Typen ein:

Organization im BaseLayout (jede Seite) — logo als ImageObject angeben, nicht als einfache URL. sameAs mit Social-Profilen ergänzen, sobald diese existieren.
WebSite auf der Startseite — ermöglicht die Sitelinks-Suchbox in den Google-Ergebnissen.
BreadcrumbList auf allen Unterseiten.
Article / NewsArticle auf Blog- und News-Beiträgen — immer datePublished, dateModified und author angeben.
Product + Offer auf Produktseiten.
FAQPage auf FAQ-Abschnitten — ein wertvolles Rich Snippet, das regelmäßig als aufklappbare Antworten in SERPs erscheint.

Performance

Bild-Ladestrategien:

Hero / LCP-Bild: loading="eager" fetchpriority="high" decoding="async"
Alles unterhalb des sichtbaren Bereichs: loading="lazy" decoding="async"

Selbst gehostete Fonts im WOFF2-Format mit font-display: swap verwenden. Google Fonts fügt bei jedem Seitenaufruf einen Drittanbieter-Request hinzu, was sowohl Performance als auch DSGVO-Konformität beeinträchtigt.

Preconnect-Hints für Analytics-Domains im <head> setzen:

<link rel="preconnect" href="https://plausible.yourdomain.com" />

Security Headers (`public/_headers`)

/*
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()
  Content-Security-Policy: default-src 'self'; ...

X-XSS-Protection nicht hinzufügen. Der Header ist veraltet und verursacht in manchen Browsern Probleme. Wir entfernen ihn regelmäßig, wenn er aus alter Gewohnheit hinzugefügt wurde.

Der CSP-script-src muss alle Analytics- und Drittanbieter-Skript-Domains enthalten. Nach dem Hinzufügen externer Skripte die CSP prüfen.

DSGVO

Plausible als Analytics nutzen — selbst gehostet bedeutet, dass kein Cookie-Consent-Banner nötig ist und keine Daten die eigene Infrastruktur verlassen. Cloudflare Web Analytics (RUM) nicht aktivieren — es setzt einen Cookie und erfordert einen Consent-Flow.

Alle Auftragsverarbeiter in der Datenschutzerklärung aufführen: Cloudflare CDN, Analytics-Anbieter, Error-Tracker, E-Mail-API, Zahlungsdienstleister. DPAs für Verarbeiter unterzeichnen, die das erfordern. Funktionale Cookies (Sprachpräferenz, Theme) müssen in der Datenschutzerklärung offengelegt werden, benötigen aber keinen Consent-Banner.

Cloudflare-Setup

www → Apex 301-Redirect: Cloudflare Redirect Rules verwenden, nicht Page Rules (die sind eingestellt). Regel: http.host eq "www.yourdomain.com" → https://yourdomain.com${http.request.uri.path} (301). Der www-DNS-CNAME muss proxied sein (orange Wolke).

E-Mail-Verschleierung deaktivieren: Zone → Scrape Shield → Email Address Obfuscation → Off. Cloudflares E-Mail-Verschleierung ersetzt mailto:-Links durch JavaScript und bricht damit Kontaktlinks auf schwer nachvollziehbare Weise.

Cloudflare Web Analytics nicht aktivieren. Wir haben es auf allen unseren Zonen deaktiviert — bei selbst gehosteter Analytics ist es überflüssiger Overhead.

DNS und E-Mail

Für jede Domain, die E-Mails versendet:

SPF-Record: v=spf1 include:email-provider ~all
DKIM: wird vom E-Mail-Provider bereitgestellt
DMARC: mit p=none; rua=mailto:dmarc@yourdomain.com starten. 2–4 Wochen beobachten, dann auf p=quarantine härten. Nicht direkt p=reject ohne rua-Tag setzen — dann lehnt man E-Mails ab, ohne zu sehen, welche das sind.

Kontaktformulare

Jedes Formular braucht ein Honeypot-Feld (kein CAPTCHA — schlechte UX), HTML-Escaping aller Eingaben und eine CORS-Origin-Prüfung. Rate Limiting lohnt sich, sobald der Traffic das rechtfertigt.

Launch-Tag

Das GitHub-Repository mit Cloudflare Pages verbinden und den ersten Deploy auslösen. Custom Domain in Pages → Custom domains hinzufügen und HTTPS-Aktivierung prüfen. Dann:

Sitemap bei der Google Search Console einreichen: https://yourdomain.com/sitemap-index.xml
Bei Bing Webmaster Tools einreichen (deckt ca. 10% zusätzliche Reichweite ab)
Site zu Plausible hinzufügen
Site zu Uptime Kuma hinzufügen

Erste Woche

In der GSC den Coverage-Tab auf Crawl-Fehler prüfen. URL Inspection auf der Startseite ausführen, um die Indexierung zu bestätigen. URL Inspection auf www.yourdomain.com ausführen — sollte “URL ist nicht bei Google” zeigen (Redirect funktioniert). In Plausible prüfen, ob Analytics aufzeichnet.

In der zweiten bis vierten Woche: Seiten identifizieren, die in der GSC auf Position 11–20 ranken und Impressionen haben — das sind die Kandidaten mit dem leichtesten Content-Optimierungspotenzial. Google Business Profile anfragen, falls es sich um eine lokale oder produktorientierte Site handelt. Erste Kunden nach Bewertungen fragen.

Typische Fehler

Fehler	Lösung
OG-Bild ist SVG	WebP oder PNG verwenden, 1200×675. SVG wird von allen Social-Scrapern ignoriert
`Astro.url.pathname` verliert Trailing Slash in SSG	Immer den `_pathname`-Guard verwenden (siehe Canonical-Abschnitt oben)
`X-XSS-Protection`-Header hinzugefügt	Entfernen
Named Slot `slot="head"` funktioniert nicht	BaseLayout muss `<slot name="head" />` innerhalb von `<head>` haben
Cloudflare E-Mail-Verschleierung aktiv gelassen	Sofort deaktivieren — sie bricht `mailto:`-Links
Fehlende explizite Canonical bei Layout-Varianten	Wenn das Layout die Canonical nicht aus der URL ableitet, muss sie auf jeder Seite explizit übergeben werden