Web Design and Development

A redesign that looks better and performs worse is a common and expensive outcome. It happens because the brief was about appearance and the measurement was about revenue.

The sites I build start from what the business needs a visitor to do, and what search engines and AI systems need to be able to read. Appearance follows from that rather than leading it.

Most of this work arrives attached to a search engagement, which is the sensible order: decide what pages need to exist and what they must say, then build them.

What gets built in

Every build carries the same foundations, because retrofitting them costs more than including them.

Clean, extensionless URLs with one canonical host and single-hop redirects from every legacy spelling. Structured data for the entity, the services and the questions, so the site can be parsed rather than only read. Fast rendering on a phone, since that is where the traffic is. Accessible markup with real focus states and sensible heading order. And analytics wired to the actions that matter, not just pageviews.

That last one gets missed constantly. A site that cannot tell you which page produced an enquiry is a site you cannot improve.

Migrations, and how they go wrong

A rebuild is the single most common way a business loses its search visibility, and the mechanism is nearly always the same. URLs change, redirects are partial, and the pages that were ranking quietly return errors while everyone admires the new design.

The discipline that prevents it: inventory every indexed URL before anything changes, map each one to its destination, and verify every redirect resolves in a single hop after launch. Then watch coverage for a month, because the damage shows up on a delay.

I have audited sites that lost half their impressions to exactly this, months after the fact, with nobody having connected the two events.

Choosing a platform

WordPress when non-technical people need to publish often and plugins genuinely help. Shopify when you are selling products and want the commerce problems solved for you. A static build when the content changes rarely and you want the thing to be fast and unbreakable. A framework build when there is real application behaviour.

The decision should follow from who edits the site and how often, not from what is fashionable. A business with one person publishing monthly does not need a headless architecture, and giving them one usually means nothing gets published.

Who writes the content

The honest answer is that this decides project timelines more often than any technical factor. A build waits on copy far more often than copy waits on a build.

Three arrangements work. I write it, which happens when the build is attached to a search engagement and the page structure follows from the keyword work. You write it against a per-page brief that specifies what each section must cover and why. Or a writer you already use works from the same brief.

What does not work is starting a build with the content undecided and the assumption that it will be sorted out later. That is the single most common reason a redesign slips by months.

Accessibility, briefly and practically

The commercial argument is simpler than the compliance one: a site that is hard to use with a keyboard, hard to read at low contrast, or unusable with a screen reader is losing enquiries from people who were ready to make one.

The measures that carry most of the benefit are unremarkable. Real focus states so keyboard users can see where they are. Heading order that reflects the actual structure of the page. Text contrast that holds at normal sizes. Form fields with labels rather than placeholders doing double duty. Images with alt text that says something, and empty alt on decoration so screen readers skip it.

None of that constrains the design meaningfully, and retrofitting it later costs several times what including it costs.

Before you brief a rebuild

Two things are worth settling first, because they decide the timeline more than any design decision.

Who writes the copy, and by when. And whether this is genuinely a rebuild or a set of fixes to what exists, since the second is often cheaper and lower risk than the conversation usually assumes.

If the site is currently ranking for anything, the migration plan matters more than the design brief. That is the part I would want to talk about first.

What the engagement includes

Search foundations from the start. Clean URLs, one canonical host, structured data, correct status codes and single-hop redirects, built in rather than retrofitted.
Conversion paths that are measured. The actions that matter wired to analytics, so you can tell which page produced an enquiry.
Performance and accessibility. Fast on a phone, keyboard navigable, real focus states, sensible heading order.
A safe migration. Every indexed URL inventoried and mapped before launch, every redirect verified single-hop afterwards, coverage watched for a month.
A handover you can use. Documentation and access so your team can edit and extend without coming back to me for routine changes.

How the work runs

Define the jobs. What each page is for and what a visitor should do next. Structure before appearance.
Inventory before changing. On a rebuild, every indexed URL captured and mapped to a destination first.
Build with the foundations in. URLs, schema, performance, accessibility and analytics as part of the build.
Verify the migration. Every redirect single-hop, every important page returning the right status, checked after launch.
Hand over. Access, documentation and enough training that routine changes do not need me.

Proof

Where a rebuild is paired with search work, the sequence and the results are shown in the industrial distribution case study.

Talk about your situation

The first conversation is short and mostly questions. Get in touch and tell me what you are trying to fix.

Frequently Asked Questions (FAQs)

Will a redesign hurt my search rankings?

It can, and it is the most common cause of a sudden visibility loss. The risk comes from changing URLs without complete redirects. Inventorying every indexed URL before launch, mapping each to a destination and verifying every redirect resolves in one hop afterwards prevents nearly all of it.

Which platform should I use?

It depends on who edits the site and how often. WordPress suits frequent publishing by non-technical staff. Shopify suits selling products. A static build suits content that changes rarely and rewards speed. The wrong answer is choosing on fashion, which usually leaves a business with something nobody publishes to.

Do you build the content as well?

Usually yes, when the build is attached to a search engagement, because deciding what the pages must say is most of the work. For a pure build, a content brief per page is supplied so your team or a writer can fill it.

What happens after launch?

Redirects and status codes verified, analytics confirmed to be recording the actions that matter, and search coverage watched for a month since migration damage appears on a delay. After that, handover documentation so routine changes do not need me.

How long does a build take?

A focused marketing site is typically four to eight weeks, and the variable is almost always content rather than build time. A rebuild of a site that currently ranks takes longer, because the URL inventory, redirect mapping and post-launch verification are not steps worth compressing.

Do you host the site as well?

Hosting can be arranged, but owning it yourself is usually better. A site you control on your own account is one you can move, and it avoids the situation where changing supplier means renegotiating access to your own website. The handover includes what you need to run it wherever it lives.