Web design and SEO: why splitting them costs you rankings

You commission the web design and SEO gets left for later. You sign off the mock-up after two rounds. You go live.

Three months later you hire someone to ‘do the SEO’ on what’s already built, and that person tells you that fixing the structure means changing the URLs, redoing the headings and setting up a redirect map.

There’s a popular idea that SEO is a layer you add at the end, like varnish on a piece of wood. Spoiler: it isn’t.

SEO isn’t a layer. It’s the consequence of decisions made much earlier, back in the wireframe, when someone decides how the sections are grouped and which elements are going to move as you scroll.

The cost of doing it in the wrong order

An accounting comparison works well here because it’s exact: fixing SEO after launch is like filing your tax return late. You pay what you’d have paid on time, plus the late-filing penalty on top.

That penalty comes in three different forms.

The first is money, because rebuilding a URL architecture takes more hours than defining it properly in the wireframe, now that there’s content, links and rankings to protect.

The second is time, because a structural change needs weeks for Google to reprocess the site, and you can’t shorten that period by paying more.

The third is the one nobody ever invoices: the rankings you never got during the months your website was badly planned.

No varnish at the end.

URL architecture is decided in the wireframe

This is the most expensive decision to reverse and the one most often made by default, without anyone really choosing it.

When someone sketches the section map they’re deciding, without realising it, which pages will compete for which queries. If your business has five services and the wireframe crams them into a single page with anchor links, you’ve just given up five pages that could each have ranked on their own.

It works the other way round too: if you create a page for every variation of the same thing, you’ve manufactured cannibalisation before writing a single line.

Three questions need answering before anyone builds anything:

• Which pages are going to have a life of their own in search? Those need their own URL, their own title and enough content to stand on their own two feet.
• Which groupings are navigation and which ones are content? A dropdown in the menu doesn’t create a page, whereas a section with its own search intent does.
• How is this going to grow over the next two years? If the URL pattern has no room to grow, every new service you add will force you to improvise.

When all this gets defined after launch, the fix involves 301 redirects and accepting a temporary loss of visibility. It’s exactly what happens with sites launched on a template’s ready-made structure, where the sitemap is simply whatever the template came with.

Visual hierarchy and semantic hierarchy aren’t the same thing

A designer orders things by size, colour and position, while a crawler orders them by tags.

When those two hierarchies don’t match, you end up with a page that reads perfectly for people and that search engines interpret back to front.

These are the three mismatches I come across most often:

• The big headline that isn’t the H1. It was built as styled text because it looked better that way, and the page ends up with no main heading at all or inherits one from the theme.
• Decorative H2s. Short lines of visual filler tagged as headings, which clutter the table of contents and muddle the document outline.
• Important content hidden in closed tabs or accordions. It does get indexed, but most visitors never open it, so the argument you’re counting on goes unread.

None of the three gets fixed with a plugin. They get fixed by deciding, at the design stage, what counts as structure and what counts as decoration.

‘Semantic hierarchy isn’t a technical requirement getting in design’s way: it is the design, told in a language that machines understand.’

Every visual effect has a price in JavaScript

Scroll animations, counters that tick upwards, carousels and fade-in effects aren’t free. Each one adds work that the user’s browser has to run before the page can respond.

You pay that cost in responsiveness, which is one of the metrics Google measures with real users. You’ll find the exact thresholds in measuring and fixing LCP, INP and CLS on WordPress, so I won’t repeat them here.

What does belong in this article is the design decision about which effects get to stay.

The rule I use is a simple one. An effect stays if it communicates something the user needs to understand (a state, a hierarchy, a transition between steps), and it goes if all it proves is that we know how to build it.

When an effect gets into the design without that filter and reaches development as an approved requirement, it’s already too late, because removing it afterwards means an awkward conversation with whoever signed off the mock-up.

Images, where design and performance really clash

This is the most frequent conflict between what the design wants and what the search engine needs.

Design asks for big full-screen photos, while performance asks for the smallest file possible. Both of them are right, and the answer isn’t for one of them to win.

The answer is four decisions that get made in the mock-up:

• Real dimensions for every slot. Knowing what size each image will be displayed at lets you serve it at that size, and not at the size it came out of the camera.
• Modern format. A heavy JPG converted to WebP or AVIF loses between 30% and 50% of its weight with no visible difference.
• Reserved space. Declaring the width and height stops content jumping around while it loads, which is exactly what causes the wrong click.
• Which image comes first. The header image is never deferred, and every image below it is.

None of the four limits creativity. All of them limit improvisation, which is a very different thing.

When it’s done the other way round, you get what I describe in what every second of waiting costs you on mobile: traffic that arrives and leaves before it has seen anything at all.

Prevention versus cure

This table sums up the whole article: the same decision, made before launch or after it.

The difference between the two columns isn’t the quality of the end result. It’s how much it costs you to get there.

How web design and SEO fit together in practice

Integrating SEO and design doesn’t mean a specialist reviews the mock-up at the end. It means three specific moments in the project.

The three moments where it all gets decided

Before the wireframe, you define the content map: which pages exist, which search each one targets and how they relate to each other. That document shapes the design, not the other way round.

During design, the hierarchy gets tagged, so every block in the mock-up is labelled H1, H2, H3 or body text in the same way it’s labelled with its colour.

Before launch, you check what broke along the way, because something always does. That’s where checking what’s failing before Google notices comes in, and it’s why that work costs half as much when it lands on a well-planned site.

It’s the same order I follow in how I run a project from start to finish: think first, draw second.

WordPress web design and SEO: what the CMS decides for you

On WordPress there are SEO decisions that, if you don’t make them on purpose, the theme and the page builder will make for you by default.

• Permalinks. They’re set on day one and then left alone, because changing them once content is published sends you straight back to 301 redirects.
• The theme’s headings. Plenty of themes print their own H1 or turn widget titles into H2s, and you check that in the HTML, not in the visual editor.
• The pages WordPress creates on its own. Tags, author archives, date archives and attachment pages generate indexable URLs that are empty or duplicated, so you switch them off or mark them noindex from the start.
• The page builder’s weight. Every nested container is HTML and CSS the browser has to process. A page builder used well doesn’t penalise you, but one used for absolutely everything does.

An SEO plugin takes care of titles, descriptions and the sitemap. It doesn’t take care of any of the four things above, because that’s technical SEO. That’s why custom WordPress development starts by reviewing everything the CMS does on its own.

What you see when this isn’t done

A beautiful website that doesn’t show up anywhere. It’s the pattern I keep finding in audits of small business websites that bring in nothing, and the same one behind an online shop that quietly stops selling.

It also happens the other way round, and it’s worth saying: websites that are technically spotless, with a flawless structure, that don’t convert because nobody thought about the journey of whoever lands on them. That’s what designing for how users really move through a page is about.

The two halves need each other. A website that ranks and doesn’t convert brings you visitors who don’t buy, and one that converts and doesn’t rank only converts the people who already knew you.

I don’t split the two phases, because you can’t split them without paying the penalty. The content map and the wireframe come out in the same week, and the hierarchy gets tagged in the mock-up rather than afterwards. You can see what changes when it’s done this way in projects where this was measured.