1. Der Kunde
WattDevis.fr ist eine französische B2C-Lead-Generierungs-Plattform, die Privatpersonen mit RGE-zertifizierten Installateuren für zwei Vertikalen erneuerbarer Energien verbindet: private Photovoltaik-Anlagen und Ladestationen für Elektrofahrzeuge. Das Geschäftsmodell ist ein 4-stufiges Lead-Scoring (hot, warm, cool, cold) mit Verteilung an Partner-Installateure basierend auf Einsatzgebieten.
Das Projekt wird autonom von einem einzigen Gründer geführt. Interne redaktionelle Produktion, kein externes Marketing-Team.
2. Anfängliche Ziele
Drei gleichzeitige Anforderungen, die die Zielarchitektur definiert haben:
- Maximale Performance. Mobile Lighthouse 100/100 auf allen vier Metriken (Performance, Accessibility, Best Practices, SEO) erreichen, ohne den redaktionellen Inhalt zu kompromittieren.
- Redaktionelle Skalierung. Kapazität, 600+ technische Artikel (regionale Guides, Vergleiche, Glossar, Produktdatenblätter) zu publizieren und zu pflegen, ohne Performance-Einbußen.
- NIS2-/DSGVO-konforme Sicherheit. Mozilla Observatory A+ Score mit gehärteten Sicherheits-Headern (HSTS preload, strikte CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy).
Die Gleichzeitigkeit dieser drei Anforderungen hat die Migration zu einer statischen Cloudflare-HTML-Architektur gerechtfertigt. Für einen Kunden mit nur Anforderung Nr. 3 (Sicherheit) bleibt ein leichterer Ansatz die richtige Wahl — siehe Abschnitt 5.
3. Anfangszustand — WordPress auf Hostinger
Sicherheits-Header (Mozilla Observatory)
| Test | Status | Strafpunkte |
|---|---|---|
| Strict-Transport-Security | Fehlt | −20 |
| Content-Security-Policy | Fehlt | −25 |
| X-Content-Type-Options | Fehlt | −5 |
| X-Frame-Options | Fehlt | −20 |
| Referrer-Policy | Fehlt | −5 |
| X-Powered-By | PHP/8.2.30 sichtbar | negatives Signal |
Mozilla Observatory Score: 30/100, Note D, 6/10 bestandene Tests. Dies ist die Standardkonfiguration einer nicht-gehärteten WordPress-Installation — etwa 70 % der WordPress-Sites in Produktion bleiben ohne spezifischen Eingriff auf diesem Niveau.
Mobile Lighthouse
| Metrik | WP roh (geschätzt) | WP optimiert auf Hostinger |
|---|---|---|
| Performance | ~60 | 90 |
| Accessibility | ~70-80 | 94 |
| Best Practices | variabel | 100 |
| SEO | ~85 | 100 |
Der Sprung von 60 zu 90 bei Performance wurde durch LiteSpeed-Cache, Brotli-Kompression, Lazy Loading und WebP-Bildkonvertierung erreicht. Diese Optimierung erforderte einen Inhalts-Kompromiss — einige Seiten wurden unvollständig gehalten, um den Score zu erhalten, was für den Produktionsstart nicht akzeptabel war.
4. Der Entscheidungspunkt: Migration
- Inhalt-vs-Performance-Engpass. Mobile Lighthouse 100 mit gleichzeitig 600+ vollständigen Artikeln war auf Hostinger ohne unverhältnismäßige laufende Optimierungs-Investitionen nicht erreichbar.
- Plugin-bedingter Sicherheits-Engpass. Mozilla A+ über WordPress-Plugins zu erreichen kollidierte mit dem LiteSpeed-Cache und erzeugte wiederkehrende Wartungskosten (jedes Plugin-Update konnte die CSP brechen).
- Skalierbarkeits-Engpass. Die NIS2-Konformität (in Kraft seit Oktober 2024) erforderte mittelfristig regelmäßige Sicherheits-Audits. Die WordPress-Härtung über die Zeit aufrechtzuerhalten erforderte ein wiederkehrendes Budget, das das Projekt nicht autonom tragen konnte.
- Redaktionelle Produktivität durch KI-Assistenten. Der Gründer wollte Claude — oder Cursor mit Anbindung an das Git-Repository — bitten können, Artikel zu produzieren, Stadt-Seiten zu bearbeiten und technische Seiten innerhalb von Minuten automatisch anzupassen. Eine statische HTML-Architektur auf Git ist nativ kompatibel mit diesem KI-First-Workflow; ein WordPress mit Gutenberg, Datenbank und Plugins erfordert systematische manuelle Vermittlung. Dieses Kriterium wog in der finalen Entscheidung genauso schwer wie die drei vorhergehenden strukturellen Engpässe.
- Messbarer ökologischer Fußabdruck (sekundäres Motiv). Das WordPress auf Hostinger übertrug typischerweise 2 bis 5 MB pro Seitenaufruf (PHP-Core, Plugins, nicht-optimierte Bilder, Drittanbieter-Skripte). Der Post-Migration-Stack mit statischem HTML liefert dieselbe Startseite in 300 KB bis 1 MB je nach Inhalt — ein 5- bis 10-mal leichteres Verhältnis. Bei gleichem Besucher-Volumen bedeutet das eingesparte Bandbreite und vermiedene CO2-Emissionen pro Besuch. Referenz-Methodik: websitecarbon.com. Dieses Motiv war nicht entscheidend, passt aber zur angestrebten digitalen Sobrietät.
Die Entscheidung lief auf eine einfache Kosten-Nutzen-Rechnung hinaus: die Zeitkosten der Migration (5 Tage) waren niedriger als die kumulierten Kosten der Wartung des gehärteten WordPress über 12 Monate, und die Migration entsperrte gleichzeitig die drei Beschränkungen.
5. Wann migrieren vs. wann vor Ort härten
Wichtige Klarstellung zum Umfang dieser Case Study. Die WattDevis-Migration ist keine Demonstration, dass WordPress eine schlechte Wahl ist. Es ist eine Demonstration, dass ein Stack zu den gleichzeitigen Anforderungen des Projekts passen muss.
Hier die Entscheidungsmatrix, die HELIORANK systematisch in Erstgesprächen anwendet:
| Ihre Anforderungen | Empfohlener Ansatz | Festpreis (zzgl. MwSt.) | Lieferzeit |
|---|---|---|---|
| Nur Mozilla A+ Sicherheit (Sie behalten WordPress, keine andere Änderung) | Cloudflare Worker als Proxy vor bestehendem WordPress. Kein Hosting-Wechsel, keine Plugin-Installation. | 3.500 € | 7 Werktage |
| A+ Sicherheit + ZAP-Audit + Härtung (Sie wollen auch Pentest und NIS2-Konformität) | Vorheriges Paket + OWASP ZAP-Audit, erweiterte WP-Härtung, Cloudflare WAF Baseline gegen WP-Exploits. | 4.500 € | 10 Werktage |
| Mobile Lighthouse 100 auf bestehendem Stack | Performance Engineering (technische Refaktorierung der bestehenden Site, keine Migration). | 4.500 € | 10 Werktage |
| Alles gleichzeitig + langfristige Skalierung + häufige Edits (der WattDevis-Fall) | Migration zu Cloudflare HTML mit Git-basiertem CMS für Edits durch nicht-technische Teams. | ab 8.000 € | 4-8 Wochen |
6. Tatsächliche Timeline des WattDevis-Projekts
wattdevis.fr auf Hostinger erstellt, Theme-Auswahl, kritische Plugins installiert, redaktionelle Produktion gestartet. Progressive manuelle Optimierung bis zum Plateau bei Mobile Lighthouse 90.
Google Search Console beginnt, die Site zu erkennen und erste Impressionen zu erfassen (0 → 27 pro Tag). Durchschnittliche Position stabilisiert sich bei 16,3.
Zielarchitektur definiert. Build-Pipeline, die 680 HTML-Dateien aus Markdown-Quellen generiert. Zwei Cloudflare Workers erstellt (Lead-Intake + Tracking-Funnel). KV-Namespaces, Sicherheits-Header, Sitemap, Schema.org konfiguriert. Progressives Deployment validiert durch automatisierte Tests.
Statischer Stack vollständig deployed. Google-Indexierungsgeschwindigkeit beschleunigt außergewöhnlich: 222 → 280 → 386 → 390 tägliche Impressionen in einer Woche. Durchschnittliche Position verbessert sich auf 7,8-9,1. Mozilla Observatory wechselt offiziell zu A+.
7. Zielarchitektur
Stack
- Cloudflare Pages: Hosting für die 680 vorgenerierten statischen HTML-Dateien (kostenlos bis 100k Builds/Monat, Sub-50ms Edge-Latenz in Frankreich)
- 2 serverlose Cloudflare Workers:
- lead-intake (~1000 Zeilen, modulares ESM) — POST /api/lead/submit, Validierung, mehrschichtiger Anti-Spam, 4-stufiges Lead-Scoring, KV-Persistenz, Resend-Benachrichtigung
- tracking (~200 Zeilen) — POST /api/track/event für Funnel-Analytics, 3-stufige KV-Aggregation (pro Tag, pro A/B-Variante, pro Slug)
- 2 KV-Namespaces: LEADS_KV (90-Tage TTL) und FUNNEL_KV (Aggregation)
- Cloudflare Resend Integration: transaktionale E-Mails für Hot-/Warm-Lead-Benachrichtigungen
Strukturierende technische Entscheidungen
- Keine npm-Runtime-Abhängigkeit auf dem Backend Worker (100 % auditierbarer Code)
- Lokale Build-Pipeline (60-90 Sekunden für 680 Seiten), die AVIF/WebP/JPG-Bilder in 3 Größen generiert (600w/1200w/1920w)
- Deterministisches Cache-Busting über Content-Hash in Dateinamen
- Sauberes Schema.org auf jeder Seite (Article, FAQPage, BreadcrumbList)
- Strikte CSP ohne
'unsafe-inline'aufscript-src, externalisiertes Inline-JS, Hashes für verbleibende Elemente
8. Messbare Ergebnisse (öffentlich verifizierbar)
Mozilla Observatory
| Indikator | Vorher (WP/Hostinger) | Nachher (Cloudflare HTML) |
|---|---|---|
| Score | 30/100 | 100/100 |
| Note | D | A+ |
| Bestandene Tests | 6/10 | 10/10 |
| Strict-Transport-Security | ❌ | ✅ preload, 1 Jahr |
| Content-Security-Policy | ❌ | ✅ strikt |
| X-Frame-Options | ❌ | ✅ SAMEORIGIN |
In Echtzeit verifizierbar: Mozilla Observatory wattdevis.fr
Mobile Lighthouse
| Metrik | WP optimiert | Cloudflare HTML |
|---|---|---|
| Performance | 90 | 100 |
| Accessibility | 94 | 100 |
| Best Practices | 100 | 100 |
| SEO | 100 | 100 |
In Echtzeit verifizierbar: PageSpeed Insights wattdevis.fr
Google Search Console-Indexierung (die wichtigste Metrik)
| Datum | Impressionen | Durchschn. Position | Phase |
|---|---|---|---|
| 14.04.2026 | 0 | — | WordPress, Tag 1 indexierbar |
| 16.04.2026 | 21 | 16,3 | WordPress, erste Chunks |
| 17.04.2026 | 27 | 9,7 | HTML-Migration Start |
| 20.04.2026 | 99 | 10,6 | Migration läuft |
| 22.04.2026 | 137 | 7,9 | Migration abgeschlossen |
| 25.04.2026 | 222 | 8,6 | HTML vollständig deployed |
| 27.04.2026 | 386 | 7,8 | Indexierungs-Beschleunigung |
| 30.04.2026 | 390 | 9,1 | Stack stabilisiert (Tag 17) |
| 03.05.2026 | 374 | 7,3 | Position verbessert sich |
| 05.05.2026 | 598 | 6,9 | Kontinuierliches Wachstum (Tag 22) |
| 06.05.2026 | 608 | 8,0 | Steigende Trajektorie (Tag 23) |
Kumuliert über 23 Tage (14. April → 6. Mai 2026): 5.718 Impressionen, 40 Klicks, durchschnittliche Position 7-9 in kontinuierlicher Verbesserung. An Tag 23 liefert die Site 608 tägliche Impressionen — ein +56 %-Anstieg gegenüber dem Peak an Tag 17. Die Kurve bleibt steigend: kein Plateau, ein kontinuierlicher Anstieg nach der Architektur-Stabilisierung.
Warum diese Indexierungsgeschwindigkeit
Diese Geschwindigkeit — 0 zu 390 täglichen Impressionen in 17 Tagen auf einer Domain ohne Backlinks — ist nicht auf Domain-Autorität (sie hat keine), Backlinks (es gibt keine) oder ein Google-Ads-Budget (null) zurückzuführen. Sie ist direkt drei kumulativen technischen Faktoren zuzuschreiben:
- Statische Architektur ohne Server-Engpass — Googlebot crawlt HTML-Dateien direkt vom Cloudflare-Edge geliefert, kein PHP-Cache-Hit, kein MySQL-Timeout. Kein Server-Rate-Limit, selbst während intensiver Erkundungs-Bursts (376 Anfragen an einem einzigen Tag, 16. April 2026).
- Saubere und validierte Schema.org-strukturierte Daten auf jeder Seite (Article, FAQPage, BreadcrumbList).
- Kohärentes redaktionelles Volumen (680 Seiten) mit dichter interner Verlinkung — Google identifiziert eine thematische Autorität auf Solar/EV-Charging ab der ersten Crawl-Welle.
Crawl Health Post-Migration (15. April → 6. Mai 2026)
Daten aus dem Google Search Console Crawl Stats-Bericht über 22 Tage Post-Migration-Beobachtung:
- 3.342 Crawl-Anfragen durch Googlebot — Google crawlt die Site aktiv (~152 Anfragen/Tag im Durchschnitt).
- 93,74 % gut bediente Antworten: 87,58 % als 200 OK + 6,16 % als permanente 301-Weiterleitungen (alte WordPress-URLs umgeleitet auf migrierte Äquivalente).
- 4,85 % 404s auf alten unveröffentlichten WordPress-URLs — identifizierter Verbesserungsbereich, 301-Redirect-Mapping wird in einer zukünftigen Iteration angereichert, um die gesunde Quote über 98 % zu treiben.
- 0,42 % echte Fehler (5XX Server + DNS + andere 4XX) — sehr niedrige Schwelle, die die Stabilität der Cloudflare Pages-Infrastruktur belegt.
- 62,42 % des Crawls durch Googlebot Smartphone — Indexierung läuft mobile-first, konsistent mit der Mobile-Lighthouse-Priorität.
- „Keine Probleme" gemeldet von Google Search Console zur globalen Crawl-Gesundheit.
Server-TTFB-Stabilisierung (April → Mai 2026)
Die direkt von Google gemessene Server-Antwortzeit hat sich von einer initial erhöhten Phase (469 bis 970 ms Mitte April, während sich die Edge-Caches an den regionalen Cloudflare-PoPs stabilisierten) zu einem stabilen Regime bei 120–128 ms im Mai 2026 entwickelt. Das ist 6- bis 12-mal schneller als ein durchschnittliches nicht-optimiertes WordPress (typische TTFB 800–1.500 ms). Diese Edge-Performance ist nun die technische Grundlage für die nächste Wachstumsphase, unabhängig vom initialen Indexierungs-Schub.
Multi-Engine KI-Sichtbarkeit (Bing-/Copilot-Ökosystem)
Unabhängig von der Google-Indexierung wird die Site von Bing Webmaster Tools in seinem „AI Performance Overview"-Tab verfolgt, der Zitate über das KI-Ökosystem aggregiert, das vom Bing-Index angetrieben wird: Bing Copilot (Microsoft), ChatGPT search (verwendet Bing als Backend), Perplexity (kombiniert Brave + Bing).
| Datum | KI-Zitate | Zitierte Seiten |
|---|---|---|
| 17.04.2026 → 20.04.2026 | 0 | 0 |
| 21.04.2026 | 3 | 2 |
| 22.04.2026 → 25.04.2026 | 0 | 0 |
| 26.04.2026 | 1 | 1 |
| 27.04.2026 | 9 | 2 |
| 28.04.2026 | 6 | 1 |
| 29.04.2026 | 10 | 1 |
| 30.04.2026 | 0 | 0 |
Kumuliert über 14 Tage: 29 KI-Zitate, 5 aktive Tage von 14, Peak bei 10 Zitaten/Tag. Gleichzeitige Multi-Engine-Abdeckung: Microsoft Copilot, ChatGPT, Perplexity.
Warum dieses Signal unabhängig von Google zählt: Google AI Overviews und Google AI Mode verwenden ihre eigenen Modelle und ihren eigenen Index. Bing treibt ein eigenständiges Ökosystem an (Copilot, ChatGPT, Perplexity). Sichtbarkeit auf diesen beiden unabhängigen algorithmischen Polen zu erreichen, belegt, dass die technische Methodik (sauberes Schema.org, strukturierte llms.txt, Crawl-Geschwindigkeit, kohärente thematische Autorität) Signale produziert, die von allen großen KI-Antwortsystemen erkannt werden — konsistent über das gesamte KI-Ökosystem.
Direktes ChatGPT-Zitat (anonyme Sitzung, 5. Mai 2026). Auf die kommerzielle Anfrage « comparateur de devis photovoltaïque en France » [DE: „Photovoltaik-Angebotsvergleich in Frankreich"] zitiert ChatGPT spontan WattDevis neben den etablierten Markt-Vergleichern, mit einer beschreibenden Zeile, die die redaktionelle Transparenz hervorhebt („3 schnelle Angebote ohne aggressive Kaltakquise, hebt die Förderungs-Gesamttransparenz hervor"). Für eine 14 Monate alte Domain ohne bezahlte Backlinks ist diese Präsenz in den nativen ChatGPT-Empfehlungen ein direkter Beweis organischer thematischer Autorität im Bereich erneuerbare Energien.
Hinweis: Antworten von konversationellen KI-Engines sind nicht-deterministisch. Das beobachtete Zitat ist zum Datum indikativ und kann sich mit Modell- und Index-Updates ändern.
9. Was diese Case Study NICHT behauptet
Um jede Überinterpretation zu vermeiden, hier was nicht durch WattDevis demonstriert wird:
- Keine Kritik an WordPress. WordPress bleibt ein exzellentes CMS für Projekte mit häufigen redaktionellen Bedürfnissen durch nicht-technische Teams. Das Mozilla A+ WordPress Paket (3.500 €) belegt, dass maximale Sicherheit erreichbar ist, ohne WordPress zu verlassen.
- Keine Migrationspflicht für A+. Mozilla A+ ist auf WordPress über Cloudflare Worker Proxy (Paket 3.500 €) oder erweiterte Worker-Härtung (Pro-Paket 4.500 €) erreichbar.
- Keine Zusage von 390 Impressionen/Tag. Indexierungsvolumen hängen von redaktioneller Qualität und Zielmarkt ab. Die bei WattDevis beobachtete Geschwindigkeit ist außergewöhnlich, aber mit vergleichbarer redaktioneller Disziplin reproduzierbar.
- Keine Garantie für Position 1. Eine Lighthouse 100 + Mozilla A+ Site optimiert die INDEXIERUNG (Crawl-Geschwindigkeit + technische Qualität). Die finalen Positionen hängen dann vom Inhalt, vom Wettbewerb und von Signalen ab, die diese Case Study nicht abdeckt.