WattDevis.fr: Von Mozilla D zu A+

Auf einen Blick — Situation, Maßnahme, Ergebnis

Das Detail, Abschnitt für Abschnitt, unten — vom Kundenkontext (Abschnitt 1) bis zur FAQ (Abschnitt 10).

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:

1. Maximale Performance. Mobile Lighthouse 100/100 auf allen vier Metriken (Performance, Accessibility, Best Practices, SEO) erreichen, ohne den redaktionellen Inhalt zu kompromittieren.
2. Redaktionelle Skalierung. Kapazität, 600+ technische Artikel (regionale Guides, Vergleiche, Glossar, Produktdatenblätter) zu publizieren und zu pflegen, ohne Performance-Einbußen.
3. 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)

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

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

1. 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.
2. 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).
3. 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.
4. 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.
5. 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:

6. Tatsächliche Timeline des WattDevis-Projekts

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' auf script-src, externalisiertes Inline-JS, Hashes für verbleibende Elemente

8. Messbare Ergebnisse (öffentlich verifizierbar)

Mozilla Observatory

In Echtzeit verifizierbar: Mozilla Observatory wattdevis.fr

Mobile Lighthouse

In Echtzeit verifizierbar: PageSpeed Insights wattdevis.fr

Google Search Console-Indexierung (die wichtigste Metrik)

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).

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.

10. FAQ

Muss man von WordPress migrieren, um einen Mozilla-Observatory-A+-Score zu erreichen?

Nein. Mozilla A+ ist erreichbar, ohne WordPress zu verlassen, über einen Cloudflare Worker, der als Proxy vor die bestehende Website gesetzt wird - kein Hosting-Wechsel, kein Plugin zu installieren. Eine Migration zu statischem HTML rechtfertigt sich nur, wenn sich drei Bedürfnisse kumulieren: maximale Sicherheit, Lighthouse-100-Performance und ein redaktionelles Volumen, das dauerhaft zu pflegen ist. Für ein isoliertes Sicherheitsbedürfnis bleibt das Proxy-Paket die wirtschaftlichste Option.

Warum war die Google-Indexierung auf einer neuen Domain so schnell?

Die Geschwindigkeit - 0 bis 390 tägliche Impressionen in 17 Tagen - ist weder der Domain-Autorität noch Backlinks noch einem Werbebudget zu verdanken, alle abwesend. Sie beruht auf drei kumulativen technischen Faktoren: einer statischen Architektur, die direkt von der Cloudflare-Edge ausgeliefert wird, ohne Server-Engpass oder Timeout, die Googlebot ohne Ratenbegrenzung crawlen kann; sauberen, validierten strukturierten Schema.org-Daten auf jeder Seite; und einem kohärenten redaktionellen Volumen mit dichter interner Verlinkung, das ab der ersten Crawl-Welle eine thematische Autorität signalisiert.

Wann ist es besser, zu Cloudflare HTML zu migrieren, statt die Website vor Ort zu härten?

Die Migration kostet strukturell mehr an Anfangsaufwand, wird aber jenseits von 6 bis 12 Monaten rentabel für Projekte, die drei gleichzeitige Bedürfnisse kumulieren: Sicherheit, Performance und Content-Bearbeitung im großen Maßstab. Für ein Projekt mit einem oder zwei isolierten Bedürfnissen ist ein Mozilla-A+- oder Performance-Engineering-Paket, angewandt auf den bestehenden Stack, systematisch wirtschaftlicher und ebenso dauerhaft.

Wie lange dauert eine Migration dieser Art?

Die WattDevis-Migration erforderte 5 intensive Tage, um die 680 HTML-Dateien zu generieren, die zwei Cloudflare Workers zu erstellen und Sicherheit, Sitemap und Schema.org zu konfigurieren. Eine vollständige Migration mit Einrichtung eines git-basierten CMS für die Bearbeitung durch ein nicht-technisches Team erstreckt sich eher über 4 bis 8 Wochen.