Migrating off WordPress, without losing rankings.

WordPress still runs a large share of the web: roughly 41.5% of all websites as of mid-2026, per W3Techs, though that's actually down from a 43.6% peak in early 2025, the platform's first sustained multi-quarter decline in years. It remains a reasonable starting point for a lot of organizations. It stops being the right tool once a site needs to be fast, secure, and genuinely low-maintenance, which is exactly the migration done for SPIF.in.

The real cost of staying on WordPress

Security is the sharpest edge of this. Patchstack's own 2025 security report logged 11,334 new WordPress vulnerabilities that year, a 42% increase over the year before, the vast majority in third-party plugins rather than WordPress core itself. A plugin-heavy CMS means a plugin-heavy attack surface, and that surface needs constant patching whether or not anyone's actively using half those plugins.

Performance is the other real cost. Every active plugin adds render-blocking scripts and stylesheets a static site simply doesn't carry. That's not a marginal difference; it's the entire reason SPIF.in moved to a static architecture in the first place, given how directly page speed matters when someone's looking for a mental health resource on a slow connection.

Preserving search rankings through the move

This is the part that actually determines whether a migration goes well or badly. Every old URL, including category pages, tags, and anything under /wp-content/uploads/, needs an explicit 301 redirect mapped to its new home, or the site quietly loses whatever search authority it had built up.

On an Apache server, via .htaccess:

RewriteEngine On
Redirect 301 /legacy-page.html https://www.yourdomain.com/new-page
RedirectMatch 301 ^/category/business(.*) https://www.yourdomain.com/blog$1
RedirectMatch 301 ^/wp-content/uploads/2023/01/my-image.jpg$ https://www.yourdomain.com/assets/images/new-image.jpg

On Nginx, the equivalent lives in nginx.conf:

rewrite ^/legacy-page.html$ /new-page permanent;
rewrite ^/category/business/(.*)$ /blog/$1 permanent;

Checking the work actually held

After launch, Google Search Console's "Not Found" report needs checking regularly, weekly at minimum for the first month or two, to catch any legacy URL that didn't get mapped. Once a fix is in place, GSC's "Validate Fix" tool pushes Google to re-crawl and confirm rather than waiting for it to happen on its own schedule.

Where this actually gets tested: embedded Matterport tours

A Matterport tour embedded inside a WordPress page inherits every bit of script bloat the page is already carrying (outdated jQuery dependencies, plugin overhead, all of it), and the iframe's own load time suffers directly. On a static, custom-coded page, that overhead simply isn't there, and a heavy embed like a 3D tour loads the way it's supposed to.