Who this guide is for
This is not a tutorial. It is written for the person signing off the website: what to decide, what to insist on, and which received wisdom to ignore.
Choosing a platform
Most of the platform debate is tribal. The decision is actually fairly mechanical, and it hinges on one question: how often do non-technical people need to change things?
WordPress
Still the pragmatic answer for a large share of UK businesses. Your marketing person can add a service page, publish a case study, or change a headline without raising a ticket. Over twelve months that autonomy usually matters more than any technical advantage, because publishing frequency is the strongest content lever most businesses have.
Its weakness is not WordPress itself — it is what accumulates on top. A page builder stacked on a theme with its own builder, plus twenty plugins, produces four-second loads and a codebase nobody wants to touch. If you run WordPress, run it deliberately: one builder, few plugins, and a real update discipline.
A custom build (Next.js or similar)
Right when you need application logic, genuine speed, or precise control over technical SEO. You get server-rendered HTML, a performance ceiling far above a plugin stack, and a smaller attack surface.
The cost is editorial flexibility. Unless you also build a proper content model and admin interface — which is real work — every new landing page becomes a developer task. Budget for that or you will end up with a fast site nobody can update.
The honest test
If your answer to "who adds a new page" is "our marketing person, weekly", lean WordPress. If it is "we add pages twice a year and need the site to be fast and do things", lean custom.
What actually affects rankings
Setting aside content quality, which matters most, the technical fundamentals are unglamorous and frequently missing entirely:
- A unique title and meta description per page, within the roughly 60 and 160 character limits, written for the query rather than starting with the company name
- One H1 per page that describes the page — a surprising number of sites have none at all
- Canonical URLs, so the same content at multiple addresses does not compete with itself
- Structured data as an interlinked graph: Organization, WebSite, Service, FAQ, Article, Breadcrumb
- Open Graph and Twitter card tags, or every share on WhatsApp and LinkedIn renders blank
- A clean sitemap that excludes author archives and other pages with no search value
- Internal links, followed, organised into topic clusters
That last point deserves emphasis because the opposite advice circulates widely. Do not nofollow your internal links. PageRank is divided across the links on a page, and the share assigned to a nofollowed link is discarded rather than redistributed. Nofollowing your own links does not hoard authority; it destroys it. Nofollow external links if you wish — internal links should always be followed.
Performance, in terms that matter
Core Web Vitals are Google's measure of experience, but the business reason is simpler: slow sites lose enquiries.
Three numbers to hold your developer to:
- Largest Contentful Paint under 2.5 seconds on a mid-range phone over 4G — not on your desktop
- Interaction to Next Paint under 200 milliseconds
- Cumulative Layout Shift under 0.1 — nothing jumping as the page loads
Most failures come from four causes: unoptimised images, fonts that block rendering, third-party scripts (chat widgets, tag managers, trackers), and shipping JavaScript for features the page does not use.
Agree a performance budget before design starts. Retrofitting speed onto a design that assumes four hero videos is far more expensive than designing within a budget from the outset.
The AI-era change worth understanding
Something has genuinely shifted, and it changes an architectural decision.
AI crawlers — GPTBot, ClaudeBot, PerplexityBot, CCBot — mostly fetch raw HTML and do not execute JavaScript. Google can render JavaScript, but does so more slowly and less reliably than serving plain HTML.
The consequence: a client-rendered single-page app is close to invisible to the systems increasingly answering your customers' questions. If being cited by AI assistants matters to you, your content must be present in the initial HTML response — which means server rendering or static generation, not a React app that fetches everything after load.
The good news is that this requires no new discipline. Server-rendered semantic HTML, accurate structured data, and consistent business information are the same things good SEO always wanted.
Rebuild or repair?
Rebuilding is often the wrong answer, and agencies have an obvious incentive not to say so.
Repair when the content and structure are broadly right and the problems are technical — slow loading, missing metadata, no schema, plugin bloat. These are fixable at a fraction of a rebuild's cost, usually in weeks, with no migration risk at all.
Rebuild when the information architecture is genuinely wrong, the platform blocks what you need, or the codebase is unmaintainable. Even then, preserve every indexed URL you can.
Ask any agency recommending a rebuild what it would cost to fix the current site instead. The answer, and how readily it comes, tells you a lot.
Migrating without losing rankings
If you do rebuild, the migration is where sites get hurt. The essentials:
- Inventory every indexed URL from Search Console and your sitemap, before anything else.
- Preserve rather than redirect wherever possible. Keeping a URL exactly as it is — including its trailing slash — carries zero risk. A 301 passes most signal, but most is not all.
- Where a redirect is unavoidable, make it single-hop. Chains dilute and waste crawl budget.
- Carry over titles, descriptions and structured data. Improving them is fine; losing them is not.
- Do not launch slower than the old site. Benchmark before and after.
- Watch Search Console daily for the first month, so coverage errors are caught in days not quarters.
Expect a week or two of minor fluctuation. A well-executed migration does not produce a cliff.
What to insist on
- Fixed price against a written scope
- Full code ownership, repository included
- A performance budget agreed before design
- Every indexed URL accounted for, in writing
- Structured data on every page template
- Training so your team can publish without you
Next steps
If you are deciding between fixing what you have and starting again, that is worth a conversation rather than a proposal. We are content to tell you the cheaper option is the right one, and we frequently do.
Frequently asked
WordPress is usually right when your team publishes frequently and needs full editorial control without a developer in the loop. A custom build in Next.js wins when you need speed, application logic, or tight control over technical SEO. The deciding question is how often non-technical people need to change things.
Only if the migration is handled badly. Rankings are lost when URLs change without redirects, metadata is not carried over, or the new site is slower. The safest approach is to preserve every already-indexed URL exactly — same path, served 200, no redirect at all — because a URL that already ranks has nothing to gain from being moved.
A focused marketing site with a handful of templates starts from £4,500. A larger site with a custom content model and dozens of pages usually sits between £9,000 and £25,000. Web applications with accounts and integrations are quoted after a paid discovery phase.
Because AI crawlers such as GPTBot, ClaudeBot and PerplexityBot fetch raw HTML and largely do not execute JavaScript. A client-rendered single-page app is close to invisible to them. If you want to be cited by AI assistants as well as ranked by Google, your content has to be in the initial HTML response.
- web development
- WordPress
- Next.js
- SEO
- performance