Migrate Your WordPress Site to a Static Site

Every time someone visits your WordPress site, a sequence of events unfolds: the web server receives the request, PHP executes, PHP queries the MySQL database, the database returns data, PHP assembles HTML from the data, and the server sends the finished HTML to the visitor’s browser. This process takes 800 milliseconds to 2 seconds, depending on your hosting, your plugins, and your database size.

Here is the thing: for the vast majority of WordPress sites, the HTML output is identical for every single visitor. Your marketing page looks the same whether it is viewed from Tokyo or Toronto, by your first visitor or your ten-thousandth. You are running a full application stack — PHP runtime, MySQL database, web server, caching layer, dozens of plugins — to produce output that could be a set of files sitting on a disk.

That is what a static site is. Files on a disk, served directly by a CDN. No server processing, no database queries, no runtime. And the difference in performance, cost, and security is dramatic.

How static sites work: the technical explanation

A static site generator (Astro, Hugo, 11ty, Jekyll, and others) takes your content — typically markdown files with metadata — and your templates, and produces a directory of HTML, CSS, JavaScript, and image files at build time. This directory is then uploaded to a CDN (Content Delivery Network) that serves the files from edge locations around the world.

The request flow looks like this:

WordPress (dynamic):

Visitor → DNS → Origin Server → PHP Runtime → MySQL Query →
PHP Assembles HTML → Response sent → Visitor sees page
Latency: 800ms – 2,000ms

Static site:

Visitor → DNS → Nearest CDN Edge Node → Pre-built HTML served →
Visitor sees page
Latency: 20ms – 100ms

The static site eliminates four steps from the request chain: the origin server, the PHP runtime, the database query, and the HTML assembly. Each of those steps adds latency, introduces potential points of failure, and creates attack surface.

Why this matters for performance

The performance difference is not incremental — it is categorical.

WordPress sites serve responses from a single origin server (or a small number of servers). Even with caching plugins like WP Super Cache or W3 Total Cache, the first request to each page requires the full PHP/MySQL cycle, cached responses expire and need regeneration, and many plugins disable caching for logged-in users or specific pages.

Static sites serve every request from the CDN edge node closest to the visitor. A visitor in Singapore gets the page from Singapore. A visitor in Frankfurt gets it from Frankfurt. There is no origin server round-trip. The Time to First Byte (TTFB) is consistently under 50ms regardless of where the visitor is located.

Real numbers:

Average WordPress mobile page load time: approximately 13 seconds (according to HTTP Archive data for WordPress origins)
Static site mobile page load time: under 1 second
WordPress Core Web Vitals pass rate on mobile: 43% — the lowest among major CMS platforms
Static site CWV pass rate: consistently above 90%
WordPress average Lighthouse performance score: 40-50
Static site Lighthouse score: 95-100

These are not cherry-picked comparisons. WordPress’s performance problems are architectural. Adding caching, CDN plugins, and image optimization plugins helps, but it is patching over a fundamental mismatch: using a dynamic application to serve static content.

Why this matters for security

A static site has no server-side code executing in production. There is no PHP interpreter to exploit, no database to inject SQL into, no admin login page to brute-force, no file upload handler to abuse, no XML-RPC endpoint to attack.

The WordPress ecosystem saw 7,966 new vulnerabilities in 2024, or roughly 22 per day. The vast majority (96%) were in plugins. When a vulnerability is disclosed, attackers begin scanning for vulnerable sites within hours — while the average WordPress admin takes 14 days to apply patches.

With a static site, this entire category of concern disappears. Your “server” is a CDN serving files. There is nothing to hack.

Why this matters for cost

Static hosting is free on all major platforms. Not “free trial” or “free with limitations that matter” — genuinely free with limits that most websites will never approach:

Cloudflare Pages: unlimited bandwidth, 500 deploys per month, unlimited sites
Vercel: 100GB bandwidth per month, unlimited deploys
Netlify: 100GB bandwidth per month, 300 build minutes per month
GitHub Pages: 100GB bandwidth per month (more limited feature set)

Compare that to WordPress hosting:

Shared hosting (Bluehost, SiteGround): $3-15/month, but slow and limited
Managed hosting (WP Engine, Kinsta, Flywheel): $25-300/month
Enterprise hosting: $300-1,000+/month

And hosting is only part of the WordPress cost. Factor in maintenance — plugin updates, security monitoring, backup verification, PHP version management, database optimization — and a small business WordPress site costs $1,500-$4,000/year in hosting and maintenance combined.

A static site costs $0/year in hosting and requires zero server maintenance. You only spend time when you are actively making changes to your site.

When static works and when it doesn’t

Static sites are the right architecture when:

Every visitor sees the same content (marketing sites, blogs, portfolios, documentation, business homepages)
Content changes infrequently (daily, weekly, or monthly — not minute by minute)
Performance matters (every site, but especially sites where mobile users matter)
Security is a concern (every site, but especially sites handling sensitive information)
Budget is constrained (startups, small businesses, personal sites)

Static sites are not the right architecture when:

User authentication is core to the experience. Membership sites, gated content, user dashboards — these need server-side session management. You can add authentication to a static site using services like Auth0 or Clerk, but if your entire site is behind a login, a static architecture adds complexity.
Content changes in real time. Stock tickers, live sports scores, auction platforms — anything where content must update without a rebuild. (Note: most “real-time” WordPress sites are not actually real-time. If your blog shows “Latest Posts” that update when you publish, that is perfectly achievable with static sites — you just trigger a rebuild when you publish.)
Complex e-commerce with inventory management. Product catalog pages can absolutely be static, and many e-commerce sites use static frontends. But shopping carts, checkout flows, inventory tracking, and order management need a backend. If you have a WooCommerce store with 1,000+ products and active sales, consider Shopify or a headless commerce solution rather than going fully static.
Server-side form processing. This is a common misconception — static sites handle forms just fine. Services like Formspree, Basin, Netlify Forms, and Web3Forms provide form endpoints that work with plain HTML forms. But if you need complex multi-step forms with server-side validation and workflow automation, you will need a separate backend or a form service that supports those features.
Server-side search across large datasets. Client-side search (Pagefind, Lunr.js, Fuse.js) works well for sites with up to a few thousand pages. For larger sites, you need a search service like Algolia or Meilisearch.

For the vast majority of WordPress sites — which are marketing pages, blogs, and business homepages — static is the correct architecture.

How to migrate: your options

1. AI coding agents (most flexible — hours to days)

AI coding agents like Claude Code, Cursor, Windsurf, and Cline can handle a full WordPress-to-static migration. They read your WordPress content, scaffold a static site project, convert posts to markdown, build layouts, download images, and iterate on build errors.

The process:

Export WordPress content (Tools > Export in wp-admin, or fetch via the REST API)
Open a new project directory in your AI coding tool
Instruct: “Convert this WordPress export into a static Astro site with blog posts as markdown content collections. Download all images and match the current design.”
The agent creates the project, converts content, builds components, fixes build errors
Deploy to Cloudflare Pages, Vercel, or Netlify

Real-world examples:

Sid Bharath migrated his WordPress blog to a static site in 3 hours using Claude Code. PageSpeed went from 67 to 100, LCP from 7.2s to 0.5s, monthly hosting from $20 to $0. (Source)
cursor.com migrated from Sanity CMS to static code in 3 days for $260 in AI tokens. CDN costs dropped from $56,848/year to near-zero. (Source)
Prefect.io rebuilt their CMS-based site as static code in 1 week. New landing pages now deploy in 30 minutes instead of 2 weeks. (Source)

Cost: $20/month tool subscription + $10-50 in API tokens for a typical blog.

2. AI app builders (for non-developers — hours)

Bolt.new, v0.dev, Lovable, and Replit Agent let you describe or show what you want and get a working static site. Screenshot your WordPress pages, paste them in, and iterate from there. Good for simple sites where you don’t need fine-grained control over the output.

3. Hire a developer or agency

Freelancers charge $500-$5,000 for a WordPress-to-static migration. Agencies charge $5,000-$25,000 for complex sites. Many developers now use AI tools, which has shortened typical timelines from weeks to days and reduced costs.

4. Automated migration tools

Tools like BrowserCat Migrate automate the pipeline end-to-end: paste a URL, get a deployed static site with source code. Other automated tools handle specific parts of the process.

5. WordPress static export plugins

These are WordPress plugins that generate a static snapshot of your site:

Simply Static: Exports your entire WordPress site as static HTML files. The output is a working snapshot — visitors see the same pages — but it is not a maintainable codebase. You cannot easily edit individual pages or add new content without going back to WordPress and re-exporting.
WP2Static: Similar to Simply Static, with more deployment options (S3, GitHub Pages, Netlify, etc.). Also produces a snapshot rather than a maintainable project.

These plugins are useful as an intermediate step. You can deploy the static export immediately to get the performance and security benefits, then work on building a proper static site project at your own pace.

6. Content extraction + manual build

Extract your content with dedicated tools, then build the static site yourself:

WordPress XML Export (built-in): Tools > Export in wp-admin
WordPress REST API: Programmatic access at /wp-json/wp/v2/
wordpress-export-to-markdown: Converts XML to markdown with images
wp2md: WordPress to markdown converter

After extracting content, choose a static site generator:

Astro: Best for content sites. Zero JS by default. Built-in content collections.
Hugo: Fastest build times. Good for large sites with thousands of pages.
11ty (Eleventy): Minimal and flexible. Familiar template languages.
Jekyll: Simple, Ruby-based. Good for basic blogs. Used by GitHub Pages.

Build your layouts, organize your content, and deploy.

7. Manual migration (full control — weeks)

Do everything yourself from scratch:

Export content from WordPress
Choose a static site generator
Scaffold the project
Convert content to markdown with frontmatter
Build layouts matching your WordPress theme
Download and organize images
Replace plugin functionality (forms, search, comments)
Set up URL redirects
Test on mobile and across browsers
Deploy

This takes 2-6 weeks for a typical site. You get complete understanding of every file.

The migration in detail: what you need to handle

Content conversion

WordPress stores post content as HTML in the database. If you use Gutenberg, the HTML contains block comments like . You need to convert this to markdown. Simple content (paragraphs, headings, lists, images, links) converts cleanly. Complex blocks (columns, galleries, tables, custom blocks from plugins) require manual handling.

The best conversion tools strip WordPress block comments and convert the underlying HTML to markdown. Image references need to be updated to point to your new image locations.

Images

WordPress stores images in /wp-content/uploads/YYYY/MM/ and generates multiple sizes (thumbnail, medium, large, full). You need to decide which sizes to keep, download them, and update references.

Static site generators have built-in image optimization. Astro’s astro:assets and Hugo’s image processing can resize, compress, and convert images at build time. You can download the full-size originals and let the build step handle optimization, which is usually better than keeping WordPress’s pre-generated sizes.

Forms

WordPress contact forms (Contact Form 7, WPForms, Gravity Forms) need replacement. Options for static sites:

Formspree: Free for 50 submissions/month, $8/month for more. Drop-in form endpoint.
Basin: Free for 100 submissions/month. Simple API-based forms.
Netlify Forms: Free if you are on Netlify. Built into the platform.
Web3Forms: Free for 250 submissions/month. No backend needed.

All of these work with plain HTML forms. You replace the WordPress form shortcode with a <form> tag pointing to the service’s endpoint.

SEO

Preserve your search rankings by:

Matching URL structure exactly, or setting up 301 redirects
Porting meta titles and descriptions from Yoast/RankMath to frontmatter
Generating an XML sitemap (most static site generators have plugins for this)
Submitting the new sitemap to Google Search Console
Setting up proper canonical URLs
Preserving structured data / JSON-LD if you were using it

Google’s guidance on site migrations recommends monitoring Search Console for crawl errors and expecting a brief ranking fluctuation (1-4 weeks) during the transition.

Comments

If your blog has comments, you need a solution:

Giscus: Powered by GitHub Discussions. Free, no tracking. Requires GitHub account to comment.
Disqus: Full-featured but adds tracking scripts and ads on free tier.
Utterances: Similar to Giscus but uses GitHub Issues.
Cusdis: Lightweight, privacy-focused, self-hosted option.
Export and display statically: If you just want to preserve existing comments without new ones, export them and render as static HTML.

What life looks like after going static

The build-deploy cycle

When you make a change to your static site — edit a blog post, update a page, add an image — you commit the change to Git and push. Your hosting platform detects the push, runs the build (usually 10-60 seconds for Astro or 11ty, sub-second for Hugo), and deploys the new files to the CDN. The entire cycle from edit to live site takes 1-2 minutes.

This is different from WordPress, where changes are live the instant you click “Publish.” For most sites, a 1-2 minute delay is not meaningful. Your blog post being live at 10:01 AM instead of 10:00 AM does not matter.

For sites that need faster updates, most static site generators support incremental builds and some hosting platforms support incremental deployment, reducing the cycle to seconds.

Content editing for non-technical users

The most common objection to static sites is “but my team uses wp-admin.” There are real solutions:

Decap CMS (formerly Netlify CMS): Free, open-source CMS that provides a wp-admin-like editing interface backed by Git. Your content team sees a familiar dashboard with rich text editing; under the hood, changes become Git commits to markdown files.
Tina CMS: Visual editing with live preview. See changes in real-time as you type.
Sanity, Contentful, Strapi: Full headless CMS platforms. More powerful but introduce a CMS dependency (which you might be trying to avoid).
GitHub web editor: For simple edits, GitHub’s built-in file editor is sufficient. Open the markdown file, edit, commit.

Monitoring and maintenance

With WordPress, maintenance is a regular chore: update core, update plugins, update themes, check for compatibility issues, monitor for security vulnerabilities, optimize the database, manage backups.

With a static site, maintenance is minimal. Your site is files on a CDN. There is no server to patch, no database to optimize, no plugins to update. Your dependencies (the static site generator and any build-time plugins) can be updated at your convenience — they affect the build process, not the live site. If you never update them, your site continues to work exactly as it does today.