On this page
- Why Migrate from WordPress
- Performance
- Security
- Plugin Abandonment
- The WordPress Governance Crisis
- How the Converter Works
- Step-by-Step Migration
- 1. Audit Your WordPress Site
- 2. Set Up the Target Site
- 3. Convert Pages
- 4. Review and Clean Up
- 5. Redirect Strategy
- 6. Enhance with Wire
- 7. Post-Migration Monitoring
- Parallel Operation
- What You Lose
- The Numbers That Matter
The average website migration takes 523 days to recover organic traffic. 17% of migrations never recover at all. These numbers come from Search Engine Journal's 2024 study tracking migrations over 1,000+ days via Ahrefs data. The failures share a pattern: broken redirects, lost metadata, and URL structure changes that sever accumulated ranking signals.
Wire's migration avoids these failures because it preserves every SEO signal during conversion: titles, descriptions, dates, heading structure, internal links, and images. The URL structure is yours to control. No WordPress export files needed. One command per page.
Why Migrate from WordPress
Performance
WordPress sites load 400KB-2MB of PHP-generated HTML per page, execute 15-30 database queries, and assemble output from multiple plugin outputs. Lighthouse performance scores plateau at 70-80 even with aggressive optimization.
Static sites built with Wire serve pre-rendered HTML. No database. No PHP. A WordPress-to-Astro migration documented by Kashif Aziz went from Lighthouse 70-80 to a perfect 100. Wire-built sites consistently score 95+.
| Metric | WordPress (typical) | Wire static |
|---|---|---|
| Page weight | 400KB-2MB | Under 50KB |
| Largest Contentful Paint | 2-4 seconds | Under 1.5 seconds |
| Server response (TTFB) | 200-800ms | Under 50ms |
| Cumulative Layout Shift | 0.1-0.3 | Under 0.05 |
| DOM nodes | 800-2,000 | Under 200 |
Google's John Mueller describes Core Web Vitals as "not giant factors in ranking" but more than a tiebreaker. Perficient's study found CWV is a gate: passing it does not boost rankings, failing it suppresses them. WordPress sites with heavy plugin stacks frequently fail the LCP threshold (2.5s). Wire clears it with room to spare.
Security
Patchstack's 2025 and 2026 reports paint a stark picture:
- 11,334 new vulnerabilities disclosed in WordPress ecosystem in 2025 (42% increase over 2024)
- 91% of vulnerabilities are in plugins, not WordPress core
- 46% unpatched at the time of disclosure
- Median time to first exploitation after disclosure: 5 hours
- 20% of heavily exploited vulnerabilities were attacked within 6 hours
A static site has no server-side code to exploit. No database to breach. No plugins to patch. The attack surface drops to the hosting provider and DNS.
Sources: Patchstack 2025, Patchstack 2026.
Plugin Abandonment
59% of WordPress plugins (34,000+) have not been updated in over two years. 22.7% have never been updated after initial upload. Every abandoned plugin is a potential security hole and a performance drag that does not get fixed.
Sites with 20+ active plugins show significantly slower load times (Kinsta study). Each plugin adds its own CSS, JavaScript, and database queries. Removing them is not always possible because other plugins or the theme depend on them.
Source: Fuad Al Azad plugin analysis.
The WordPress Governance Crisis
WordPress market share dropped from 43.5% to 42.6% in 2025, the first meaningful decline in its history. The trigger: Matt Mullenweg blocked WP Engine (hosting 1M+ WordPress sites) from WordPress.org resources in September 2024. 159 Automattic employees took severance packages. A court ordered access restored in December 2024. A class action lawsuit followed.
For site owners, the signal is clear: WordPress governance is no longer stable. Betting a business on a platform where one person can cut off a major hosting provider is a risk that did not exist two years ago.
Sources: W3Techs, TechCrunch.
How the Converter Works
Wire's wp.py module fetches a WordPress page and extracts everything from the rendered HTML. No WordPress admin access or export files needed.
The extraction follows a priority chain:
- JSON-LD (Yoast SEO). Richest metadata: title, description, dates, author, word count, article section, language, thumbnail.
- OpenGraph tags. Title, description, image. Used when JSON-LD is absent.
- Meta tags. Description fallback.
- HTML elements.
<time>tags for dates,<h1>for title.
If your WordPress site uses Yoast SEO, the converter gets everything from JSON-LD. If not, it falls back gracefully.
| WordPress element | Wire output |
|---|---|
| Title (JSON-LD/OG/H1) | title: in frontmatter |
| Meta description | description: in frontmatter |
| Publication date | created: in frontmatter |
| Modified date | date: in frontmatter |
| Author name | author: in frontmatter |
| Body HTML | Clean markdown (markdownify) |
| Inline images | Downloaded to docs/assets/images/ |
| Headings | Preserved as markdown headings |
| Internal links | Converted to relative paths |
| External links | Preserved as-is |
Step-by-Step Migration
1. Audit Your WordPress Site
Not every WordPress page deserves migration. AutoFix München had 67 pages on WordPress. After connecting GSC, the audit showed 22 pages with zero impressions and no inbound links. Those got deleted, not migrated. The remaining 45 became the Wire site.
python -m wire.chief data
python -m wire.chief audit
Focus on pages with impressions. Pages with zero impressions and no internal links are candidates for deletion.
2. Set Up the Target Site
mkdir autofix-muenchen && cd autofix-muenchen
python -m wire.build --init
See Getting Started for the full setup.
3. Convert Pages
from wire.wp import download_page
from pathlib import Path
docs_dir = Path("docs")
# Download a single page
msg, ok = download_page("bremsen", "services", "https://autofix-muenchen.de", docs_dir)
print(msg) # Shows extracted metadata and save location
This creates docs/services/bremsen/index.md with full frontmatter and clean markdown. Images download to docs/assets/images/.
4. Review and Clean Up
The markdown output is clean but not perfect. Common issues:
Shortcodes. WordPress shortcodes ([gallery], [contact-form]) are stripped during conversion. Replace with native content or remove.
Plugin blocks. Gutenberg blocks from third-party plugins (Divi, WPBakery, Elementor) produce proprietary markup that does not convert to clean markdown. Standard blocks (headings, paragraphs, images, lists) convert cleanly.
ACF fields. Advanced Custom Fields store image references by WordPress post ID. These IDs do not transfer. Any ACF-driven content needs manual review after conversion.
JSON-LD and structured data. Yoast, Rank Math, and Schema Pro generate JSON-LD at render time, not in stored content. Wire's build system generates its own JSON-LD from frontmatter. No data is lost, but the schema changes from plugin-generated to build-generated.
5. Redirect Strategy
Google follows up to ~10 redirect hops, but each hop wastes crawl budget and passes slightly less signal. Use single-hop 301 redirects.
# .htaccess or hosting provider config
Redirect 301 /alte-seite/bremsen/ /services/bremsen/
Google recommends keeping 301 redirects for at least 1 year. The Change of Address tool forwards signals for 180 days. Do not redirect all old pages to the homepage. Google treats that as a soft 404.
If the URL structure stays identical, no redirects are needed. This is the safest path.
6. Enhance with Wire
Once pages are in markdown, Wire's full pipeline is available:
python -m wire.chief audit services
python -m wire.chief enrich services
python -m wire.chief crosslink services
python -m wire.build
7. Post-Migration Monitoring
The critical window is 4-6 weeks. Google needs time to recrawl and reindex.
# Run weekly
python -m wire.chief data
python -m wire.chief audit
Watch for:
- Indexing status. Verify Google indexed static URLs, not old WordPress URLs.
- Impression stability. Should remain stable or increase as CWV improves.
- 404 errors. URL structure changes create broken links. The sanitize command detects and fixes these.
- Redirect chains. If old redirects chain through intermediate URLs, consolidate them to single hops.
Parallel Operation
You do not have to migrate everything at once. CompareStack migrated in batches of 20 vendor profiles per week over 10 weeks:
- Migrate highest-traffic pages first (top 20% by impressions)
- Set up 301 redirects from WordPress to static for each batch
- Monitor GSC data for 1-2 weeks before the next batch
- Keep low-traffic pages on WordPress until migrated or deleted
This approach limits blast radius. If something breaks, it affects 20 pages, not 200.
What You Lose
Be honest about trade-offs:
- Comments. WordPress has built-in commenting. Static sites need a third-party service or no comments.
- Dynamic forms. Contact forms and user accounts require external services or JavaScript.
- Real-time content. Static sites show the same HTML to everyone. No per-user personalization.
- Plugin ecosystem. WordPress has 59,000+ plugins (59% abandoned). Wire has 12 modules that all work together.
For content sites where search traffic is the primary goal, these trade-offs are favorable. AutoFix München did not use comments, had one contact form (replaced with a phone number and email), and needed zero personalization. CompareStack replaced their contact form with Tally and never looked back.
The Numbers That Matter
| Metric | Source | Number |
|---|---|---|
| Average migration recovery time | Search Engine Journal, 2024 | 523 days |
| Migrations that never recover | Search Engine Journal, 2024 | 17% |
| WordPress plugin vulnerabilities (2025) | Patchstack | 11,334 |
| Plugins unpatched at disclosure | Patchstack | 46% |
| Median time to exploitation | Patchstack | 5 hours |
| Abandoned plugins (2+ years) | Fuad Al Azad | 59% |
| WordPress market share decline | W3Techs | 43.5% to 42.6% |
| Static site Lighthouse scores | Multiple benchmarks | 95+ |
| WordPress Lighthouse scores | Multiple benchmarks | 60-80 |
The migration itself takes a day for a small site (45 pages), a few weeks for a large one (200+ pages done in batches). The recovery, if done correctly with preserved URLs and proper redirects, takes days, not the 523-day average that afflicts botched migrations.
Related: adding a site and post-migration.
See the Guides overview for all Wire documentation.