We moved goatpixels.com off WordPress. Here's the redirect map.

This site used to be WordPress. It is now a hand-built Next.js application: no theme, no plugins, no page builder, one small SQLite database for the client portal. This is the checklist we ran on ourselves — the same one we run for clients — with the actual redirect map, including the pages we decided to kill.

Why move at all?

Three reasons that also apply to most businesses reading this.

• Speed. The old site loaded the theme, the builder and every plugin's scripts before the first word. The new one loads the page, then draws the galaxy on top of it. A hand-built site passes Core Web Vitals by default; a page-builder site has to be nursed into it.
• Ownership. Every line is ours. Nothing to license, nothing that breaks on a plugin update at 23:00 on a Friday.
• Focus. WordPress kept tempting us to publish plugin-shaped content. More on that below.

Step 1: inventory every URL that exists

Not the pages you remember — the URLs Google has. We pulled three lists and merged them: the old sitemap, Search Console's "indexed pages" export, and a crawl of the live site. That is how you find the /home and /about-us/ duplicates, the trailing-slash variants and the blog posts everyone forgot.

For a site our size that was a few dozen URLs. For a webshop it is thousands, and the same rule applies: every URL with impressions in the last 16 months gets a destination.

Step 2: map each old URL to its closest real equivalent

Google's own guidance is blunt: redirecting everything to the homepage collapses the relevance you built. Each old page maps to the page that answers the same intent. Ours, shortened:

/home, /home/            → /
/about-us, /about-us/    → /about
/contact-us, /contact-us/→ /contact
/project/fastmotors      → /work/fast-motors
/project/:slug           → /work/:slug

All of them are permanent (301) redirects, and none of them chain. /about-us/ goes straight to /about, not via /about-us.

Step 3: decide what deserves to die

Here is the part most migration guides skip. The old blog had sixteen posts with titles like "best WordPress hosting for SEO", "cheap web hosting hidden costs" and "how to use AI for web design". They ranked a little. They brought people who wanted €3 hosting, not businesses that wanted a website.

We did not migrate them. Each one redirects to the page that serves the intent behind it: the hosting and speed posts to SEO services, the design tips to services, the rest to the blog. Sixteen thin posts became three pages with a point, and the site stopped telling Google we were a hosting review blog.

The lesson generalises: a migration is the one moment you can prune without anyone noticing. Use it.

Step 4: carry the metadata over by hand

Titles, meta descriptions and canonical tags do not move with the content — the new platform generates its own. We rebuilt every title from the old one where it worked, and rewrote it where it did not. Structured data was rebuilt from scratch: one ProfessionalService entity for the company with a stable @id, BlogPosting on every article, and one source of truth for the company facts that feeds both the page copy and the JSON-LD, so they can never drift apart. That last detail matters more every month, because AI answer engines read entities, not pages — we learned that the hard way.

Step 5: launch in the right order

1. Redirects live before the new site is public, tested against the full inventory with a script, not by clicking.
2. New sitemap submitted in Search Console the same hour.
3. Old sitemap left online for two weeks so Google recrawls the old URLs and finds the 301s faster.
4. Search Console checked daily for a month: crawl errors, "page with redirect" counts falling, impressions per page holding.

What to expect

A 10–30% dip for two to eight weeks is normal even on a clean migration; Google is re-evaluating every page. What is not normal is a dip that is still there at week ten — that means a redirect gap or a metadata regression, and both are findable in Search Console if you kept the inventory from step 1.

When you should not leave WordPress

If your team publishes daily and lives in the editor, if you run WooCommerce with a warehouse plugged into it, or if the site is simply not the problem — stay. We build on WordPress and WooCommerce when it is the right call: our own theme and our own plugins on top, nothing freemium underneath. The ordering site we are finishing for a 1923 Amsterdam butcher works exactly like that.

Planning a replatform or a rebrand and worried about the rankings you already have? Send us the current domain — we will tell you what is at risk before you sign anything.