In brief — situation, action, result
| Starting situation | Action | Result |
|---|---|---|
| WordPress on Hostinger: Mozilla D (30/100), mobile Lighthouse 90 | Migration to static HTML on Cloudflare Pages + 2 serverless Workers | Mozilla A+ (100/100), Lighthouse 100/100/100/100 |
| Brand-new domain, 0 Google impressions, no backlinks | 680 HTML pages, clean Schema.org, Cloudflare edge sub-50 ms | 608 impressions/day 23 days after launch, average position 7-9 |
| Security headers absent (HSTS, CSP, X-Frame-Options) | Hardened headers, NIS2/GDPR-ready configuration | 10/10 Mozilla Observatory tests passed |
The detail, section by section, below — from the client context (section 1) to the FAQ (section 10).
1. The client
WattDevis.fr is a French B2C lead-generation platform connecting individuals with RGE-certified installers for two renewable-energy verticals: residential photovoltaic systems and electric-vehicle charging stations. The business model is 4-tier lead scoring (hot, warm, cool, cold) with distribution to partner installers based on coverage zones.
The project is run autonomously by a solo founder. In-house editorial production, no external marketing team.
2. Initial objectives
Three simultaneous requirements that defined the target architecture:
- Maximum performance. Reach mobile Lighthouse 100/100 across all four metrics (Performance, Accessibility, Best Practices, SEO) without compromising editorial content.
- Editorial scale. Capacity to publish and maintain 600+ technical articles (regional guides, comparators, glossary, product sheets) without performance degradation.
- NIS2/GDPR-ready security. Mozilla Observatory A+ score with hardened security headers (HSTS preload, strict CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy).
The combination of these three requirements is what justified migrating to a static Cloudflare HTML architecture. For a client with only requirement #3 (security), a lighter approach remains the right call — see section 5.
3. Initial state — WordPress on Hostinger
Security headers (Mozilla Observatory)
| Test | Status | Penalty |
|---|---|---|
| Strict-Transport-Security | Missing | −20 |
| Content-Security-Policy | Missing | −25 |
| X-Content-Type-Options | Missing | −5 |
| X-Frame-Options | Missing | −20 |
| Referrer-Policy | Missing | −5 |
| X-Powered-By | PHP/8.2.30 exposed | negative signal |
Mozilla Observatory score: 30/100, grade D, 6/10 tests passing. This is the default configuration for a non-hardened WordPress install — roughly 70% of WordPress sites in production stay at this level absent a specific intervention.
Mobile Lighthouse
| Metric | Raw WP (estimated) | WP optimised on Hostinger |
|---|---|---|
| Performance | ~60 | 90 |
| Accessibility | ~70-80 | 94 |
| Best Practices | variable | 100 |
| SEO | ~85 | 100 |
The jump from 60 to 90 on Performance was achieved via LiteSpeed cache, Brotli compression, lazy loading and WebP image conversion. This optimization required a content trade-off — some pages were kept incomplete to preserve the score, which was not acceptable for the production launch.
4. The decision point: migrating
- Performance bottleneck. Mobile Lighthouse 100 with 600+ complete articles simultaneously was not reachable on Hostinger without disproportionate continuous-optimisation investment.
- Plugin-dependent security constraint. Reaching Mozilla A+ via WordPress plugins conflicted with LiteSpeed cache and created recurring maintenance costs (every plugin update could break the CSP).
- Long-term scalability limit. NIS2 compliance (in force October 2024) implied periodic security audits over time. Maintaining WordPress hardening over the long run required a recurring budget the project could not absorb autonomously.
- Editorial productivity through AI assistants. The founder wanted to ask Claude — or Cursor connected to the Git repository — to produce articles, edit city pages, and adjust technical pages automatically within minutes. A static HTML architecture on Git is natively compatible with this AI-first flow; a WordPress with Gutenberg, database and plugins requires systematic manual mediation. This criterion weighed as much as the three preceding technical constraints in the final decision.
- Bandwidth and energy footprint (secondary motive). The static stack transfers 300 KB to 1 MB per page load, against 2 to 5 MB on the previous WordPress build — a 5 to 10× lighter ratio. At equivalent traffic, this means significantly less bandwidth consumed per visit. Methodology reference: websitecarbon.com.
The decision came down to a simple calculation: the time cost of migration (5 days) was lower than the cumulative cost of maintaining the hardened WordPress over 12 months, and migration unblocked the three constraints simultaneously.
5. When to migrate vs when to harden in place
An important clarification on the scope of this case study. The WattDevis migration is not a demonstration that WordPress is a bad choice. It is a demonstration that a stack must match the simultaneous needs of the project.
Below is the decision matrix HELIORANK applies systematically during discovery calls:
| Your needs | Recommended approach | Fixed fee (excl. VAT) | Lead time |
|---|---|---|---|
| Mozilla A+ security only (you keep WordPress, no other change) | Cloudflare Worker as a proxy in front of existing WordPress. No hosting change, no plugin to install. | €3,500 | 7 business days |
| A+ security + ZAP audit + hardening (you also want pentest and NIS2 compliance) | Previous pack + OWASP ZAP audit, advanced WP hardening, Cloudflare WAF baseline against WP exploits. | €4,500 | 10 business days |
| Mobile Lighthouse 100 on existing stack | Performance Engineering (technical refactor on the existing site, no migration). | €4,500 | 10 business days |
| Everything simultaneously + long-term scale + frequent editing (the WattDevis case) | Migration to Cloudflare HTML with git-based CMS for non-technical team editing. | from €8,000 | 4-8 weeks |
6. Real timeline of the WattDevis engagement
wattdevis.fr created on Hostinger, theme selection, critical plugins installed, editorial production starts. Progressive manual optimization up to the mobile Lighthouse 90 ceiling.
Google Search Console begins detecting the site and recording first impressions (0 → 27 per day). Average position stabilizes around 16.3.
Target architecture defined. Build pipeline generating 680 HTML files from Markdown sources. Two Cloudflare Workers created (lead capture + tracking funnel). KV namespaces, security headers, sitemap, schema.org configured. Progressive deployment validated by automated tests.
Static stack fully deployed. Google indexing velocity accelerates exceptionally: 222 → 280 → 386 → 390 daily impressions in one week. Average position improves to 7.8-9.1. Mozilla Observatory officially flips to A+.
7. Target architecture
Stack
- Cloudflare Pages: hosting for the 680 pre-generated static HTML files (free up to 100k builds/month, sub-50ms edge latency in France)
- 2 serverless Cloudflare Workers:
- lead-intake (~1000 lines, modular ESM) — POST /api/lead/submit, validation, multi-layer anti-spam, 4-tier lead scoring, KV persistence, Resend notification
- tracking (~200 lines) — POST /api/track/event for funnel analytics, 3-level KV aggregation (per day, per A/B variant, per slug)
- 2 KV namespaces: LEADS_KV (90-day TTL) and FUNNEL_KV (aggregation)
- Cloudflare Resend integration: transactional email for hot/warm lead notifications
Structuring technical choices
- No npm runtime dependency on the backend Worker (100% auditable code)
- Local build pipeline (60-90 seconds for 680 pages) generating AVIF/WebP/JPG images at 3 sizes (600w/1200w/1920w)
- Deterministic cache busting via content hash in filenames
- Clean Schema.org on every page (Article, FAQPage, BreadcrumbList)
- Strict CSP without
'unsafe-inline'onscript-src, externalized inline JS, hashes for remaining elements
8. Measurable results (publicly verifiable)
Mozilla Observatory
| Indicator | Before (WP/Hostinger) | After (Cloudflare HTML) |
|---|---|---|
| Score | 30/100 | 100/100 |
| Grade | D | A+ |
| Tests passing | 6/10 | 10/10 |
| Strict-Transport-Security | ❌ | ✅ preload, 1 year |
| Content-Security-Policy | ❌ | ✅ strict |
| X-Frame-Options | ❌ | ✅ SAMEORIGIN |
Verifiable in real time: Mozilla Observatory wattdevis.fr
Mobile Lighthouse
| Metric | WP optimised | Cloudflare HTML |
|---|---|---|
| Performance | 90 | 100 |
| Accessibility | 94 | 100 |
| Best Practices | 100 | 100 |
| SEO | 100 | 100 |
Verifiable in real time: PageSpeed Insights wattdevis.fr
Google Search Console indexing (key metric)
| Date | Impressions | Average position | Phase |
|---|---|---|---|
| 2026-04-14 | 0 | — | WordPress, day 1 indexable |
| 2026-04-16 | 21 | 16.3 | WordPress, first chunks |
| 2026-04-17 | 27 | 9.7 | HTML migration start |
| 2026-04-20 | 99 | 10.6 | Migration in progress |
| 2026-04-22 | 137 | 7.9 | Migration complete |
| 2026-04-25 | 222 | 8.6 | HTML fully deployed |
| 2026-04-27 | 386 | 7.8 | Indexing acceleration |
| 2026-04-30 | 390 | 9.1 | Stack stabilized (D+17) |
| 2026-05-03 | 374 | 7.3 | Average position improving |
| 2026-05-05 | 598 | 6.9 | Continuous growth (D+22) |
| 2026-05-06 | 608 | 8.0 | Ascending trajectory (day 23) |
Cumulative over 23 days (14 April → 6 May 2026): 5,718 impressions, 40 clicks, average position 7-9 in continuous improvement. At day 23, the site serves 608 daily impressions — a +56% increase over the day-17 peak. The curve remains ascending: not a plateau, a continuous climb after architecture stabilization.
Why this indexing velocity
This velocity — 0 to 390 daily impressions in 17 days on a domain with no backlinks — is not due to domain authority (it has none), backlinks (there are none), or a Google Ads budget (zero). It is directly attributable to three cumulative technical factors:
- Static architecture without server bottleneck — Googlebot crawls HTML files served directly from the Cloudflare edge, no PHP cache hit, no MySQL timeout. No server rate limit, even during intense exploration bursts (376 requests in a single day on 16 April 2026).
- Clean and validated Schema.org structured data on every page (Article, FAQPage, BreadcrumbList).
- Coherent editorial volume (680 pages) with dense internal linking — Google identifies a topical authority on solar/EV-charging from the first crawl wave.
Crawl health post-migration (15 April → 6 May 2026)
Data extracted from the Google Search Console Crawl Stats report over 22 days of post-migration observation:
- 3,342 crawl requests by Googlebot — Google actively crawls the site (~152 requests/day on average).
- 93.74% successful requests: 87.58% HTTP 200 OK + 6.16% permanent 301 redirects (legacy WordPress URLs redirected to their migrated equivalents).
- 4.85% 404s on legacy unpublished WordPress URLs — identified improvement area, 301 redirect mapping to be enriched in a future iteration to push the healthy ratio above 98%.
- 0.42% real errors (5XX server + DNS + other 4XX) — very low threshold indicating Cloudflare Pages infrastructure stability.
- 62.42% of crawl by Googlebot Smartphone — indexing runs mobile-first, consistent with the mobile Lighthouse priority.
- "No issues" reported by Google Search Console on overall crawl health.
Server TTFB stabilization (April → May 2026)
Server response time as measured directly by Google evolved from an initial elevated phase (469 to 970 ms in mid-April, while edge caches stabilized across regional Cloudflare PoPs) to a steady regime at 120-128 ms in May 2026. That is 6 to 12 times faster than an average non-optimised WordPress (typical TTFB 800-1,500 ms). This edge performance is now the technical baseline for the next growth phase, independent of the initial indexing surge.
Multi-engine AI visibility — ChatGPT, Microsoft Copilot, Perplexity (Bing ecosystem)
Independent of Google indexing, the site is tracked by Bing Webmaster Tools in its "AI Performance Overview" tab, which aggregates citations across the AI ecosystem powered by the Bing index: Bing Copilot (Microsoft), ChatGPT search (using Bing as backend), Perplexity (combining Brave + Bing).
| Date | AI citations | Pages cited |
|---|---|---|
| 2026-04-17 → 2026-04-20 | 0 | 0 |
| 2026-04-21 | 3 | 2 |
| 2026-04-22 → 2026-04-25 | 0 | 0 |
| 2026-04-26 | 1 | 1 |
| 2026-04-27 | 9 | 2 |
| 2026-04-28 | 6 | 1 |
| 2026-04-29 | 10 | 1 |
| 2026-04-30 | 0 | 0 |
Cumulative over 14 days: 29 AI citations, 5 active days out of 14, peak of 10 citations/day. Simultaneous multi-engine coverage: Microsoft Copilot, ChatGPT, Perplexity.
Why this signal matters independently of Google: Google AI Overviews and Google AI Mode use their own models and their own index. Bing powers a distinct ecosystem (Copilot, ChatGPT, Perplexity). Reaching visibility on these two independent algorithmic poles demonstrates that the technical methodology (clean schema.org, structured llms.txt, crawl velocity, coherent topical authority) produces signals recognised consistently across the AI ecosystem — not isolated to a single engine.
Direct ChatGPT citation (anonymous session, 2026-05-05). On the commercial query "photovoltaic quote comparator in France", ChatGPT spontaneously cites WattDevis alongside established market comparators, with a descriptive line emphasizing editorial transparency ("3 quick quotes without aggressive cold-calling, highlights all-in subsidy transparency"). For a 14-month-old domain with no paid backlinks, this presence in ChatGPT's native recommendations is direct evidence of organic topical authority on the renewable-energy vertical.
Note: responses from conversational AI engines are non-deterministic. The observed citation is indicative as of the date and may vary as models and indexes are updated.
9. What this case study does NOT claim
To prevent any over-reading, here is what is not demonstrated by WattDevis:
- Not a critique of WordPress. WordPress remains an excellent CMS for projects with frequent editorial needs by non-technical teams. The Mozilla A+ WordPress Pack (€3,500) proves you can reach maximum security without leaving WordPress.
- Not an obligation to migrate to get A+. Mozilla A+ is reachable on WordPress via Cloudflare Worker proxy (Pack €3,500) or advanced Worker hardening (Pro Pack €4,500).
- Not a promise of 390 impressions/day. Indexing volumes depend on editorial quality and target market. The velocity observed at WattDevis is exceptional but reproducible with comparable editorial discipline.
- Not a guarantee of position 1. A Lighthouse 100 + Mozilla A+ site optimises INDEXING (crawl velocity + technical quality). Final positions then depend on content, competition, and signals not covered by this case study.
10. FAQ
Do you have to migrate from WordPress to reach a Mozilla Observatory A+ score?
No. Mozilla A+ is reachable without leaving WordPress, via a Cloudflare Worker placed as a proxy in front of the existing site - no hosting change, no plugin to install. Migration to static HTML is only justified when three needs combine: maximum security, Lighthouse 100 performance and editorial volume to maintain over time. For an isolated security need, the proxy pack remains the most economical option.
Why was Google indexing so fast on a brand-new domain?
The velocity - 0 to 390 daily impressions in 17 days - is due neither to domain authority, nor to backlinks, nor to an advertising budget, all absent. It comes from three cumulative technical factors: a static architecture served directly by the Cloudflare edge, with no server bottleneck or timeout, which Googlebot can crawl without rate limit; clean, validated Schema.org structured data on every page; and a coherent editorial volume with dense internal linking, which signals topical authority from the first crawl wave.
When is it better to migrate to Cloudflare HTML rather than harden the site in place?
Migration costs structurally more in initial work, but becomes profitable beyond 6 to 12 months for projects that combine three simultaneous needs: security, performance and content editing at scale. For a project with one or two isolated needs, a Mozilla A+ or Performance Engineering pack applied to the existing stack is systematically more economical and just as durable.
How long does a migration of this type take?
The WattDevis migration took 5 intensive days to generate the 680 HTML files, create the two Cloudflare Workers and configure security, sitemap and Schema.org. A full migration with a git-based CMS for editing by a non-technical team runs rather over 4 to 8 weeks.