Web Design and Development

What "SEO-friendly" should actually mean

Nearly every web agency claims it. In practice it usually means a plugin was installed. The things that matter are decided long before that, at the point where structure and technology are chosen.

• URL structure planned around how people search, not how the CMS defaults.
• Rendering that does not depend on JavaScript for primary content — a beautiful site whose text only appears after hydration is a site with an indexing problem.
• Page templates with a heading structure that matches the visual hierarchy.
• Performance budgets agreed before the design, because retrofitting speed onto a heavy build is far more expensive.
• Internal linking designed as part of the information architecture rather than added later.

Migrations are where sites lose rankings

If you have an existing site, this is the single largest risk in the project and it is entirely avoidable. Every URL that earned traffic or links needs a mapped 301 to its specific equivalent — not a bulk redirect to the homepage, which search engines treat as a soft 404 and which discards everything those pages built.

Our migrations run as a mapped exercise: full URL inventory before design starts, a destination for every URL that matters, redirects tested on staging, a crawl comparison before DNS changes, and monitoring for six weeks after. Sites that skip this routinely lose a third of their traffic and spend a quarter recovering.

Platform choice

We work with WordPress, WooCommerce, Shopify and static builds. There is no universally correct answer, and anyone who says otherwise is describing what they like building.

WordPress suits content-led sites and teams who want to edit without a developer. Shopify suits retailers who want commerce handled and can live with its constraints. Static builds suit brochure sites where speed and security matter more than editing flexibility. The right choice depends on who maintains it after we leave, which is the question most agencies do not ask.

What we do

• Information architecture built around search demand
• Design and build on the platform that fits your team
• Performance budgets agreed and enforced through the build
• Accessibility to WCAG 2.2 AA as a baseline, not an extra
• Migration planning and URL mapping
• Analytics and conversion tracking configured at launch
• Handover documentation your team can actually use

What happens after launch

The question that separates a site that stays good from one that decays. Most sites are excellent on launch day and worse every month after, because nobody owns them.

We hand over documentation written for whoever maintains it, not for a developer — how to add a page without breaking the structure, which settings not to change, and what to check after any plugin update. Where a client has no technical resource at all, we say so during scoping rather than delivering something that will quietly rot.

Timelines and what drives them

A straightforward brochure site runs four to six weeks. A content-led site with a real migration runs eight to twelve. E-commerce depends almost entirely on catalogue complexity and integrations.

The variable that actually determines the timeline is not development speed — it is content and feedback. Projects stall waiting for copy, images and sign-off, every time. We ask for a nominated decision-maker and a content deadline before starting, because a project without both will drift regardless of how fast anyone builds.

Accessibility is not optional

UK public sector bodies have legal obligations, and private businesses are subject to the Equality Act. Beyond compliance, the work that makes a site usable with a screen reader — proper headings, labelled controls, sufficient contrast, keyboard operation — is largely the same work that makes it legible to a search engine.

We build to WCAG 2.2 AA as standard rather than quoting it separately.