Migrating WordPress to Static HTML (No SSG): Best approach for shared headers, extensionless URLs &
Hi everyone,
I'm currently planning a migration for a client site moving off WordPress to a pure static HTML setup. The primary goals are max performance and preserving 100% of the existing SEO equity.
I've put together an architectural plan covering shared components, URL routing, and technical SEO, but I'd love to get feedback from experienced devs and SEOs here on the best practices before we lock it in.
Here is the quick breakdown of the proposed strategy and where I'd appreciate your input:
1.) Shared Header/Footer Strategy
Since raw static HTML lacks native include functionality, I'm weighing three options to keep a single source of truth for navigation:
Option A (Manual Copy/Paste): Hardcoding HTML on every page. Pure raw HTML for crawlers, but a maintenance nightmare.
Option B (JavaScript Fetch/Inject): Fetching header.html via JS on DOM load. Great for DRY code, but risky for SEO/crawling and causes layout flash (CLS).
Option C (Build-time Partial Assembly): Using a lightweight local build step or static script to assemble partials into static .html files before uploading to the server.
Question: Is a build-time assembly script (Option C) still the undisputed gold standard here for SEO, or are there clean server-side alternatives (like Nginx/Apache SSIs) that you prefer for simple static builds?
2.) URL Structure & Permalinks
To match WordPress's extensionless permalink structure (/partnerships/) without exposing .html extensions:
Directory Pattern: Using folder paths with index files (e.g., /partnerships/index.html).
Trailing Slash Normalization: Server-level rules forcing a uniform trailing slash to prevent duplicate content issues.
Question: Do you prefer the folder/index.html file structure, or server-level rewrite rules that drop .html extensions from flat files? Any edge-case SEO or caching caveats with either approach?
3.) Migration & Technical SEO Checklist
Our pre-launch checklist currently covers:
Strict 1:1 URL mapping from the live sitemap.xml.
Preserving title tags, meta descriptions, self-referencing canonicals, H1-H3 hierarchy, and Schema JSON-LD.
Clean separation of assets (global.css with CSS variables vs. page-specific styles, no inline CSS).
Server-level 301 redirect map on an Nginx/Apache VPS for any altered slugs.
Staging a clean path for a headless blog integration in Phase 2.
Does this cover all bases, or are there any hidden gotchas when stripping out a CMS in favor of static code?
Looking forward to hearing how you guys handle static migrations!
I'm currently planning a migration for a client site moving off WordPress to a pure static HTML setup. The primary goals are max performance and preserving 100% of the existing SEO equity.
I've put together an architectural plan covering shared components, URL routing, and technical SEO, but I'd love to get feedback from experienced devs and SEOs here on the best practices before we lock it in.
Here is the quick breakdown of the proposed strategy and where I'd appreciate your input:
1.) Shared Header/Footer Strategy
Since raw static HTML lacks native include functionality, I'm weighing three options to keep a single source of truth for navigation:
Option A (Manual Copy/Paste): Hardcoding HTML on every page. Pure raw HTML for crawlers, but a maintenance nightmare.
Option B (JavaScript Fetch/Inject): Fetching header.html via JS on DOM load. Great for DRY code, but risky for SEO/crawling and causes layout flash (CLS).
Option C (Build-time Partial Assembly): Using a lightweight local build step or static script to assemble partials into static .html files before uploading to the server.
Question: Is a build-time assembly script (Option C) still the undisputed gold standard here for SEO, or are there clean server-side alternatives (like Nginx/Apache SSIs) that you prefer for simple static builds?
2.) URL Structure & Permalinks
To match WordPress's extensionless permalink structure (/partnerships/) without exposing .html extensions:
Directory Pattern: Using folder paths with index files (e.g., /partnerships/index.html).
Trailing Slash Normalization: Server-level rules forcing a uniform trailing slash to prevent duplicate content issues.
Question: Do you prefer the folder/index.html file structure, or server-level rewrite rules that drop .html extensions from flat files? Any edge-case SEO or caching caveats with either approach?
3.) Migration & Technical SEO Checklist
Our pre-launch checklist currently covers:
Strict 1:1 URL mapping from the live sitemap.xml.
Preserving title tags, meta descriptions, self-referencing canonicals, H1-H3 hierarchy, and Schema JSON-LD.
Clean separation of assets (global.css with CSS variables vs. page-specific styles, no inline CSS).
Server-level 301 redirect map on an Nginx/Apache VPS for any altered slugs.
Staging a clean path for a headless blog integration in Phase 2.
Does this cover all bases, or are there any hidden gotchas when stripping out a CMS in favor of static code?
Looking forward to hearing how you guys handle static migrations!
