Replacing A Slow Website Platform Without Losing Your Rankings

When the Site You Bought Becomes the Site You Regret

Every growing business hits the same wall. The website that was perfect three years ago now takes several seconds to open on a phone, every small change needs a developer, and the renewal email arrives with a number you did not expect.

The cause is rarely a bad decision. It is a platform that was designed to do everything at once: the pages, the forms, the blog, the shop, the booking, the integrations. That is a good fit on day one, when the business is small and nobody changes anything. It stops being a good fit the moment you grow, because now every part of the site is coupled to every other part.

What you notice as the owner:

• It is slow, and you can measure it. Run your own homepage through PageSpeed Insights. web.dev sets the “good” thresholds for Core Web Vitals at an LCP of 2.5 seconds, INP of 200 milliseconds or less, and CLS of 0.1 or less at the 75th percentile. Heavy builders ship large scripts, and most sites built on them land well past the first of those numbers.
• Every change has a price. A new page, a moved button, a new logo. If each one needs a developer, each one is a small project with a small invoice.
• It is expensive to keep. The renewal, plus hosting, plus the hours spent maintaining plugins, themes and updates nobody remembers installing.
• It is hard to leave. The content, the layout and the link structure all live inside the platform, so moving means rebuilding, and rebuilding risks losing the search rankings you already earned unless the URLs come with you.

┌───────────────────────────────────────────────────────────────────────────────┐
│              THE HEAVY PLATFORM VS. THE FAST STATIC SITE                      │
├─────────────────────────────────────┬─────────────────────────────────────────┤
│ THE PLATFORM THAT DOES EVERYTHING   │ THE FAST STATIC SITE                    │
├─────────────────────────────────────┼─────────────────────────────────────────┤
│ • One big editable system           │ • Files on a CDN, nothing to patch      │
│ • Ships a large JavaScript bundle   │  • Sends almost no JavaScript by default│
│ • Plugins and themes to maintain    │ • No plugins, no update treadmill       │
│ • A change needs someone to log in  │ • A change is a text file and a deploy  │
│ • Your content lives in their admin │ • Your content lives in your repo       │
│ • Hard to export, hard to leave     │ • Easy to move, easy to keep            │
└─────────────────────────────────────┴─────────────────────────────────────────┘

Moving is not about the platform being bad. It is about the platform being the wrong size for you now.

1. What the Fast Static Site Actually Is

Three layers, and nothing hidden:

┌─────────────────────────────────────────────────────────────────────────────┐
│                     THE SIMPLE STATIC ARCHITECTURE                          │
├─────────────────────────────────────────────────────────────────────────────┤
│  EDGE LAYER (Cloudflare Workers or an anycast CDN)                          │
│  ├─ SSL termination and routing in a few milliseconds                       │
│  ├─ Caching, basic security rules, and redirect rules                       │
│  └─ Sends old URLs to the new pages with permanent redirects                │
├─────────────────────────────────────────────────────────────────────────────┤
│  THE SITE (Astro + TypeScript, built to static files)                       │
│  ├─ Semantic HTML, generated once at build time                             │
│  ├─ One small interactive island where you actually need one                │
│  └─ Images converted to AVIF at build time                                  │
├─────────────────────────────────────────────────────────────────────────────┤
│  THE CONTENT (Your own repository, or a headless service)                   │
│  ├─ Written content: Markdown or MDX files you own and can edit             │
│  ├─ Products and prices: a small API or a sheet you control                 │
│  └─ Payments, email, bookings: the services that already do this well       │
└─────────────────────────────────────────────────────────────────────────────┘

Why this is easier to own than the platform you have now:

1. Your pages do not depend on a database being up. They are files. If your payment service has a bad afternoon, your pages still load.
2. The network is already built. Cloudflare reports its network spans 348 cities across 8 regions and more than 100 countries, with over 13,000 network interconnections. A static site sits on all of it at once, so a busy week, a launch or a spike in traffic changes nothing about how fast it loads.
3. Anyone can pick it up. Modern TypeScript, ordinary CSS and Astro are the tools a lot of developers already use. If your current agency disappears, the next one can read the code. That is worth more than any feature in a subscription.

2. The Phased Migration, Without a Big Bang Rewrite

The biggest fear facing an owner is the rewrite: everything is cancelled, everything is rebuilt, and for six weeks the site is broken. That fear is well earned, and it is why a phased approach exists.

The Strangler Fig pattern, described by Martin Fowler, is a gradual, incremental migration: new capabilities are added alongside the old system, the seams are identified, and behavior is moved into independently replaceable pieces. You never take the whole site down.

┌─────────────────────────────────────────────────────────────────────────────────┐
│                       THE 5-PHASE MIGRATION PLAN                                │
├─────────┬──────────────────────┬────────────────────────────────────────────────┤
│ PHASE   │ TIMING               │ WHAT HAPPENS                                   │
├─────────┼──────────────────────┼────────────────────────────────────────────────┤
│ Phase 1 │ Weeks 1-4            │ Edge router in front of the site, plus a       │
│         │                      │ performance baseline for the old pages         │
├─────────┼──────────────────────┼────────────────────────────────────────────────┤
│ Phase 2 │ Weeks 5-12           │ Homepage, top service pages and the contact    │
│         │                      │ page rebuilt and switched over, one URL at a   │
│         │                      │ time, with permanent redirects                 │
├─────────┼──────────────────────┼────────────────────────────────────────────────┤
│ Phase 3 │ Months 4-6           │ Blog, guides and case studies moved across     │
│         │                      │ so the URLs you already rank for stay live     │
├─────────┼──────────────────────┼────────────────────────────────────────────────┤
│ Phase 4 │ Months 7-9           │ Forms, calculators and the shop replaced by    │
│         │                      │ small interactive islands and live APIs        │
├─────────┼──────────────────────┼────────────────────────────────────────────────┤
│ Phase 5 │ Months 10-12         │ Old hosting and license cancelled, old         │
│         │                      │ database switched off                          │
└─────────┴──────────────────────┴────────────────────────────────────────────────┘

Phase 1 puts an edge worker in front of your domain. Everything still goes to the old site, but the worker now measures it, caches it, and holds the redirect rules it will need later.

Phase 2 is where the work shows up. The homepage and the pages that earn you money get rebuilt in Astro, and the worker sends those specific URLs to the new deployment. The pages that have moved start loading in well under a second on a phone, and you can check that yourself in PageSpeed Insights before the next phase begins.

Your rankings are protected by three things, and they are not optional: the same URLs, a permanent redirect from every old address to the new one, and the same page titles and descriptions. Search engines follow the redirect; visitors never see it.

3. The Numbers You Should Write Down

Here is the arithmetic nobody else can do for you, because it depends on your invoices. Use round numbers and replace them with yours:

┌──────────────────────────────────────────────────────────────────────────────┐
│          ILLUSTRATIVE EXAMPLE - REPLACE THESE WITH YOUR OWN NUMBERS          │
├──────────────────────────────────────────────────────────────────────────────┤
│  YOUR PLATFORM RENEWAL              $1,800 a year                            │
│  HOSTING AND ADD-ONS                $300 a year                              │
│  DEVELOPER TIME, 10 CHANGES A YEAR  10 changes x 2 hours x $75 = $1,500      │
│  ─────────────────────────────────────────────────────────────────────────── │
│  WHAT YOU PAY TO KEEP THE SITE       $3,600 a year, and every change is      │
│                                       another invoice                        │
│                                                                              │
│  ON A STATIC SITE: most of those ten changes are words and images, made      │
│  in the same editor, and cost nothing beyond the annual hosting.             │
└──────────────────────────────────────────────────────────────────────────────┘

Write down three numbers for your own site: the platform renewal, the hosting and add-ons, and the developer hours you buy in a year. The first two stop when you migrate. The third mostly stops, because a text change stops being a task for someone else. That is the whole case, and it is worth more than any percentage somebody else can quote you.

For reference, a rebuild with us starts at $1,200 for a small business site, and the scope is fixed in the proposal before anyone starts.

4. What Changes for the People Who Work on It

• New pages stop being a project. A campaign landing page is a component in the design system, not a ticket that waits for a developer.
• The design stops drifting. One set of tokens, enforced in the code, so the site still looks like itself a year after you stop looking at it.
• New tools take days, not quarters. Because the pages are separated from the data, adding a booking service or an AI assistant does not mean rebuilding the site around it.
• You can read your own site. The content is in files you own, in plain text, with a history of who changed what.

The Case for Moving

The era of the all-in-one platform that runs your whole business is ending, and the reason is not fashion. It is that the small, fast, owned site is now cheaper to run, cheaper to change and easier to hand over than the heavy one.

You do not have to do it all at once, and you should not. Move one page at a time, keep the URLs, keep the redirects, and shut the old system down when there is nothing left on it.

A site you own, on infrastructure that does not need looking after, is the quietest asset a small business can have.