Modernise an old WordPress, Joomla or 2018-era website without losing search traffic

We rebuild dated websites on a static Astro site on AWS or a modern CMS, keep every URL, title and piece of structured data that search engines rely on, and make the new site ready to be read and cited by AI search tools.
  • Every URL kept, or redirected to its final destination
  • Titles, canonicals and structured data carried over
  • Forms, analytics and consent rebuilt and tested
  • AI-readiness: crawler policy, llms.txt, structured data

Signs your site is due for modernising

Many business websites built in the 2010s have been patched ever since. The design may still be acceptable; what has aged is everything underneath it.

  • A page builder, a theme and a long list of plugins or extensions that nobody dares to update.
  • Slow pages on phones, because every page loads the builder's scripts and full-size images.
  • An old PHP or CMS version, or a hosting plan you pay for mainly so that the site stays online.
  • Forms that send spam, or enquiries that never arrive.
  • Missing or duplicate titles and descriptions, and structured data that no longer matches the page.
  • No clear decision about AI crawlers, and content that AI search tools find hard to quote.

Before choosing a rebuild, it is worth checking whether tuning would be enough: our guide to speeding up WordPress covers the usual fixes.

What a migration must preserve

A migration is judged on what it keeps. These are checked by scripts, page by page, not by eye.

URL parity and a redirect map

Every public URL from the sitemap, the CMS and a full crawl is kept at the same address, or mapped to one permanent redirect that goes straight to its final destination. No chains, no mass redirects to the home page.

SEO and structured data parity

Titles, meta descriptions, canonicals, robots rules, Open Graph tags and JSON-LD are compared tag by tag between the old and new page, and every intentional difference is written down.

Forms, analytics and consent

Contact, quote and newsletter forms are rebuilt and tested from the deployed site, with spam protection. Analytics, tag manager and cookie consent are set up before cutover, not in the week after it.

Content, media and sitemaps

Every page, post and image comes across; old upload URLs keep working or redirect; sitemaps and robots.txt are regenerated and every sitemap URL is checked to return a live, indexable page.

Where you can move to

We recommend the platform from what the site has to do, not from what is fashionable.

  • A static site (Astro on AWS). Pages are built as plain HTML ahead of time and served from Amazon S3 and CloudFront, with a small serverless function for forms. There is no server or plugin to patch, pages are fast by default, and hosting costs follow traffic. It suits sites that are mostly content plus a few forms.
  • A modern CMS-backed site. A current, maintained WordPress with a lean theme and few plugins, or a headless CMS feeding a static or server-rendered front end. It suits teams that publish daily, need logged-in users or rely on CMS features.

Our comparison of WordPress, headless and static options explains the trade-offs, and our CMS development and AWS pages describe how we build on each.

AI-readiness, built into the migration

A rebuild is the cheapest moment to make a site easy for AI search tools to read, understand and quote. None of this is a shortcut to citations; it removes the reasons a site gets skipped.

  • A deliberate crawler policy in robots.txt: which search and AI crawlers you allow, and why. Our guide to AI crawlers and robots.txt explains the choices.
  • An llms.txt and llms-full.txt generated from the site's own pages, so they never drift from what visitors see.
  • Structured data built from the text on the page: organisation, services, articles with named authors and dates, and FAQs that match the visible answers.
  • Quotable content: pages that answer the question in their first paragraph, with clear headings, dates and sources.
  • Clean, fast HTML that crawlers can read without running scripts.

How a migration works

  1. Inventory. Every URL, redirect, form, feed, search page, script, analytics tag and integration the current site has, including the ones nobody remembers.
  2. URL manifest and redirect map. Each URL is marked keep, redirect or retire, and each redirect points straight to its final destination.
  3. Build. The new templates and content, with the SEO head and structured data of every page carried over.
  4. Scripted comparison. Routes, SEO heads, page text, internal links and sitemaps are compared between the old and new site before anything goes live.
  5. Integrations and accessibility. Forms, mail, newsletter, analytics and consent are tested from the deployed site, and pages are checked at phone and desktop widths.
  6. Cutover and follow-up. DNS switch, then Search Console, 404s and redirects are watched in the weeks after launch.

Our articles on 301 redirects and the audit to run before relaunching a website go into more detail.

Our own site, before and after

In October 2026 we moved impingesolutions.com from a 2016-era WordPress install to a static Astro site on AWS. These are our own site's numbers, not a client result or a promise for yours.

  • Mobile performance: the old WordPress home page scored 44 to 54 in PageSpeed Insights, with a Largest Contentful Paint of about 15 seconds (simulated mobile lab data, 10 to 13 October 2026). The new home page scores 99 with a 2.0-second Largest Contentful Paint (Lighthouse, simulated mobile, median of three runs, 13 October 2026, after an image optimisation pass).
  • URLs: all 693 public URLs kept their address, title, canonical and structured data; 23 old URLs became permanent redirects.
  • Time: a few working days from first capture to cutover.
  • Hosting: about US$20 a month for a small VPS before; at current traffic, an estimated few dollars a month on AWS after. That second figure is an estimate until a full month's bill is in.

The full write-up, including what broke on launch day, is in what we learned moving our site from WordPress to Astro on AWS. Your results will depend on your site, so we measure before and after rather than promise a score.

Who this is for

  • Owners of WordPress, Joomla or custom sites built around 2018 or earlier that are slow, hard to update or expensive to keep running.
  • Businesses that have outgrown a site builder such as Wix and want a site they own and control.
  • Teams that want to be ready for AI search without rebuilding twice.

Who it is not for

  • A new look with nothing changing underneath: our website design service covers a redesign.
  • Sites with daily publishing, member logins or a plugin you rely on, where moving off the CMS would cost more than it saves. We will recommend modernising the CMS instead.
  • Anyone looking for a guaranteed ranking or score after launch.

What it costs and what happens after

We quote after an inventory of your current site, because the number of pages and templates, the forms and integrations, and the amount of content clean-up drive the effort. You know the price for the agreed scope, and an estimate of the monthly running cost of the new hosting, before work starts.

After launch we can look after the site under a support plan, or hand it over to your team with the redirect map and documentation. If you want to go further with AI, we offer AI search visibility work, AI assistants grounded in your content and an AI readiness audit.

What we will not do

These rules apply to every migration we take on.

  • Change or drop URLs without a redirect map you have seen.
  • Promise rankings, traffic or a performance score.
  • Go live before forms, mail and analytics have been tested on the deployed site.
  • Sell an llms.txt file or special markup as a shortcut to AI citations.
  • Publish AI-generated text on your site without a person reviewing it first.

Frequently asked questions

Will we lose search rankings if we move?

Not from the move itself, provided every page keeps its address, title, canonical and structured data, and every URL that has to change gets a permanent redirect to its final destination. Google warns that rankings can fluctuate for a while when URLs change, which is why we keep URLs wherever we can. We do not promise rankings, before or after a migration.

How long does a migration take?

It depends on the number of pages and templates, the forms and integrations, and how much content needs cleaning up. We scope it after an inventory of your current site and give you a timeline with the quote. For our own site, first capture to cutover took a few working days, with fixes continuing through the following week.

Do we have to leave WordPress or Joomla?

No. If your site needs daily publishing, logged-in users or a plugin you depend on, a modern, well-maintained CMS is often the better answer, and we will say so. A static build suits sites that are mostly content plus a few forms.

Can our team still edit the content?

Yes. On a CMS-backed site editors keep a familiar admin. On a static site, content lives in structured files or a headless CMS and every change goes through a build; we agree the editing workflow before we start building.

Do we need AWS for a static site?

No. The same shape (a static build, a content delivery network and a small function for forms) runs on other providers. We use AWS because our team runs this stack, including for our own site.

How much does it cost?

We quote after the inventory, because the number of pages and templates, the forms and integrations, and the content clean-up drive the effort. You know the price for the agreed scope before work starts, along with an estimate of the monthly running cost of the new hosting.

Start with an inventory of your current site

Send us the address and tell us what the site has to do. We will scope the inventory and tell you which way we would modernise it.

Talk to the team

Ask about modernising your site

Stay informed with our newsletter