SEO Agency for Tonbridge Businesses

SEO Is Usually Invited Too Late

The typical sequence: a business decides the website needs replacing, a designer produces something better looking, a developer builds it, everyone launches, and someone asks about SEO afterwards.

By that point most of the decisions that affect search have already been taken. What pages exist, what they are called, how they are organised, what happens to the old ones. Those are structural choices, and revisiting them after launch means undoing work rather than shaping it.

Involving search early is not about adding a large project. Often it means a couple of conversations at the right moments, which is considerably cheaper than remedial work six months later.

What to Establish Before Anything Is Designed

One thing matters more than everything else, and it takes an afternoon: know what your current site earns.

Which pages attract visibility, for which searches, and which produce enquiries. Export it. That single document informs every decision that follows — what must be preserved, what can be dropped, and what to check after launch.

Without it, a rebuild proceeds on assumptions about which pages matter, and those assumptions are frequently wrong. The page nobody rated may be the one bringing in work.

Information Architecture Comes First

How a site is organised affects both visitors and search, and it is far easier to get right at the wireframe stage than after the pages are built.

Worth deciding early: which services warrant their own page, how pages relate to one another as parents and children, what the navigation labels will be, and how deep the deepest important page sits.

These decisions are usually made on design grounds — what looks balanced in a menu, how many items fit. That is a reasonable input but not the only one. A structure reflecting how customers actually search will serve the business better than one arranged for visual symmetry.

Decide URLs Before Development Starts

URLs are set early and changed painfully. It is worth a deliberate decision rather than accepting whatever the build produces.

The principles are simple. Keep existing URLs where the page is genuinely the same — there is rarely a good reason to change an address that works. Where new URLs are needed, keep them short, readable and descriptive. Be consistent about structure. And avoid encoding things that will change, such as dates or campaign names.

Getting this wrong is not fatal, since redirects exist. But every unnecessary change adds a redirect to maintain, and a chain of them accumulates over successive rebuilds.

Planning the Content Migration

This is where rebuilds most often lose ground, and the cause is usually mundane.

A new design has a template with room for two hundred words. The old page had eight hundred, and six hundred of them get cut to fit. The page looked better and stopped ranking, because the substance it was found for is gone.

Content should drive the template rather than the reverse. If a page needs depth to be useful, the design must accommodate it. Where content genuinely is excessive, cut it deliberately after checking what the page attracts — not because a layout looked cleaner with less.

The same applies to pages themselves. Every page on the old site needs a decision: carried over, merged into something else, or retired with a redirect.

Decisions to Make While the Build Is Still Flexible

Most of what determines search performance after launch is settled during planning and development, while changes are still cheap. Working through the following before design and build progress too far turns a migration into a set of deliberate choices rather than a series of discoveries.

• Which existing URLs stay. Identify the addresses worth keeping exactly as they are, and treat them as fixed points the new build works around.
• Which URLs genuinely need to change. Restructuring should earn its place — a clearer hierarchy, or an address that actually describes the page. Change for its own sake creates work without benefit.
• Where redirects will be needed. Build the mapping as the URL decisions are made, rather than reconstructing it afterwards. Each old address gets a destination chosen deliberately.
• Which pages currently hold useful visibility. Mark them clearly so everyone involved knows which pages are load-bearing before anyone proposes removing or reshaping them.
• What content must survive intact. Agree the depth each important page needs, and design the templates to accommodate it.
• What the new architecture should be. Parent and child relationships, navigation labels and grouping, settled at wireframe stage.
• How titles and descriptions will be handled. Decide whether existing ones carry across, who writes new ones, and where they are managed in the new system.
• How internal linking will work. Which pages link to which, so that commercially important pages remain well connected in the new structure.
• What canonical rules apply. How the site will treat parameters, trailing slashes and the www question, specified rather than inherited from a default.
• What belongs in the sitemap. Which pages should be listed, how it will be generated, and what should be excluded.
• How staging stays out of search. Agree the blocking method and, critically, who is responsible for lifting it at launch and confirming it has gone.
• What gets checked at go-live. Write the launch checklist during the build, while the decisions are fresh, rather than assembling one on the day.

None of these require a large SEO engagement. They require someone to have asked the questions while the answers were still easy to act on.

Metadata, Headings and Structure

Easy to overlook during a build, and worth specifying rather than assuming.

Decide how titles and descriptions will be authored and where they live in the new system, so nobody has to retrofit them across a hundred pages after launch. Agree that heading structure will be semantic rather than purely visual — a page needs a genuine hierarchy, not several sizes of styled text.

Both are straightforward to specify in advance and tedious to correct later.

Technical Decisions Worth Making Deliberately

A short list that is quick to address at build time and awkward afterwards:

• Crawlability — whether content is reachable without interaction, and whether anything important depends on scripts to appear.
• Rendering — how the chosen approach affects what search engines can read.
• Performance — image handling and script loading decided during the build rather than optimised afterwards.
• Structured data — where it genuinely applies, planned alongside the templates that will carry it.
• Analytics and Search Console — configured for the new site before launch rather than after.

A Launch Checklist

Before go-live: redirects mapped and tested, indexing permitted on the live site, robots file correct, sitemap generated and accurate, titles and descriptions present, analytics and Search Console ready.

In the first fortnight: submit the sitemap, watch indexing in Search Console, check for crawl errors, monitor impressions on your important pages, and test key journeys on a phone.

Some fluctuation immediately after a migration is normal and does not necessarily indicate a problem. What matters is whether it settles within a few weeks.

Designers, Developers and Search People Talking

Most migration problems are communication failures rather than technical ones.

A designer trims content to improve a layout, not knowing the page ranked on it. A developer restructures URLs sensibly, unaware that redirects were needed. Neither did anything unreasonable; nobody told them.

Three conversations usually prevent this: one at planning about structure and which pages must survive, one during the build about URLs and templates, one before launch to run the checklist. Small commitments that avoid most of what goes wrong.

None of this implies every redesign needs a substantial SEO engagement. Many do not. What they need is for someone to have thought about it before decisions are locked in.

Working With a Kent-Based SEO Agency

Maidstone Digital is based in Maidstone and works with businesses in Tonbridge, elsewhere in Kent and further afield. We do not have premises in Tonbridge. For search work this makes little practical difference — it is carried out remotely and reviewed through shared data and regular conversation — though we are happy to meet where that is useful.

This page covers SEO and search marketing specifically. If you are considering something broader — web design, Webflow development, design or paid media — our digital agency services in Tonbridge page sets out the full range. For more detail on how search work is structured and delivered, see our Search Marketing services page.

SEO Tonbridge FAQs

When should SEO be involved in a website project?

At planning, before structure and page decisions are settled. That is when input costs least and matters most — which pages should exist, what they are called, what happens to the current ones. A second look during the build and a check before launch usually covers the rest. It need not be a large piece of work.

When should SEO be considered during a website redesign?

Early enough to influence the decisions that are difficult to reverse: information architecture, URLs, what content each page needs to carry, and how the migration will be handled. Reviewed only once development is complete, SEO becomes a list of things to retrofit — and some of them, particularly structural choices, are expensive to change at that stage.

This does not mean design decisions should be dictated by search. Plenty of choices about layout, visual direction and interaction have little bearing on it, and treating SEO as a veto over design produces worse websites. The aim is narrower: identify which existing pages hold value and which search considerations apply, before those decisions become costly to revisit.

In practice that means design, development and search coordinating at a few defined points rather than working sequentially. It reduces the likelihood of avoidable problems. It does not guarantee a migration free of risk — nothing does — but it makes the risks visible while there is still time to act on them.

Should we keep our existing URLs?

Where the page is genuinely the same, yes. Changing an address that works creates a redirect to maintain and gains nothing. Where structure genuinely improves — a clearer hierarchy, or URLs that actually describe the page — the change can be worth it, provided redirects are mapped properly.

What is the most important thing to do before launching?

Two things. Know which pages currently attract visibility and what happens to each of them. And confirm the site is not carrying a noindex tag or a disallow rule from the development environment. The first prevents slow, quiet losses; the second prevents a total absence from search that can go unnoticed for weeks.

How long after launch should we expect things to settle?

Some movement in the first few weeks is normal as pages are recrawled and reassessed. How long it takes depends on the size of the site and the extent of the changes. What matters is the direction: if indexing and impressions recover steadily, that is expected. If decline continues rather than levelling out, it is worth investigating properly rather than waiting.