The most expensive SEO problems we deal with are not created by SEO decisions. They are created by design decisions taken six months earlier by people who were never told search was a consideration — and by the time anyone notices, the site is live, the invoice is paid and the design agency has moved on.
This article is about the overlap: which design and build decisions affect organic visibility, at what point in the project they need to be made, and how to brief a designer so the result is both good-looking and findable. It applies equally whether you are commissioning a new site or planning a redesign of an existing one.
Most things on a website can be changed cheaply after launch. These four cannot, which is why they belong in the first two weeks of the project.
| Decision | Made when | Cost of changing later |
|---|---|---|
| URL structure | Information architecture | High: every change needs redirects and loses signal temporarily |
| Page inventory | Sitemap stage | High: missing pages mean missing rankings you never see |
| Content depth per template | Wireframes | High: a template with no room for text constrains every page built on it |
| Language and market scope | Before build | Very high: retrofitting a second language touches everything |
Design is signed off. Development starts. Someone asks about SEO in week ten. The answer is that the wireframes have no space for the content that would rank, the URL structure has already been implemented, and the launch date is committed. Everything after that is compromise.
There is no clever URL strategy, only a set of unglamorous rules that prevent problems.
Short and descriptive. /services/bathroom-renovation rather than /s/?id=447 or /services/renovation/bathroom/complete-bathroom-renovation-service-valencia. Readable by a person, stable over time.
Flat where possible. Deep nesting adds no ranking benefit and makes every future reorganisation harder. Two or three levels covers almost every local business site.
No dates or campaign names. /blog/2026/03/guide ages badly and makes updating content feel like publishing something stale. /blog/guide-slug can be refreshed indefinitely.
Decide trailing slashes and casing once. Then enforce it with a redirect rule. Sites that serve the same page at four URL variants create duplication for no reason.
Language prefix from day one. Even if you launch in one language, /en/ as a planned prefix costs nothing now and saves a migration later. This matters particularly in Valencia, where a second or third language is a realistic future step rather than a hypothetical one.
A designer builds what is on the sitemap. If the sitemap has five pages, the site has five pages, and the twenty commercial queries that needed their own page have nowhere to land.
The inventory should come from research, not from an org chart. In practice it means one page per commercial intent: not "Services" as a single page, but a page per service that someone searches for separately. Not "About us" as a catch-all, but separate pages where process, team and credentials each answer a real question.
Building it is a two-hour job with free data. Your existing impressions in Search Console analytics show which queries you already surface for, including many you never targeted, and rank tracking shows what kind of page currently ranks for each one — which tells you what kind of page you need to build.
One row per page: URL, the question it answers, the elements it must contain (price range, FAQ, gallery, conditions, form), and what it links to. Designers produce far better work from this than from "we need a services section", and it makes the wireframe review a factual conversation.
The received wisdom is that design hurts SEO through page weight. In our experience that is a minor factor compared with three others.
Pages that had two thousand words now have three hundred because the layout is cleaner. The design improved; the relevance left.
A simplified menu removes two hundred internal links overnight. Deep pages lose the signal that told Google they mattered.
Text in tabs, sliders and accordions that only load on click. Sometimes fine, often invisible - and always harder to verify.
Page weight does matter, but for conversion more than for ranking. A hero image of three megabytes on a mobile connection loses visitors before it loses positions. Fix it for the revenue reason and treat the ranking benefit as a bonus.
A template is a constraint on every page built from it. Four elements need a defined home in the design system, or the pages built on it will always be thin.
A substantial text area. Not a caption. Somewhere a service page can carry eight hundred to fifteen hundred words with proper headings, without the layout collapsing or the page looking broken.
A price or range block. Even if it says "from" or gives a range with conditions. The single most requested thing by buyers and the single most frequently absent element on local service pages.
An FAQ pattern. Real questions with real answers, structured so they are extractable. This is what feeds both featured snippets and AI answer citations.
A proof block. Photographs of actual work, named projects, credentials. It converts, it differentiates, and it gives district and sector pages a reason to exist.
If the design system has no place for these, no amount of writing later will fix it, because there is nowhere to put the writing.
The platform decision is usually made on build cost and design flexibility, and almost never on what it will cost to operate for the next five years. That operating cost is largely an SEO cost, because it determines how quickly anything can be changed.
The question that matters is not which system is "best for SEO" - almost all of them are capable - but who can change what, and how fast. A site where marketing can edit page titles, add sections and publish a new service page unaided will accumulate improvements continuously. A site where every change requires a developer sprint will accumulate a backlog instead, and the backlog is where visibility quietly dies.
Three practical checks before signing off a platform. Can a non-developer edit the title and meta description of any page? Can they add a new page in an existing template without help? Can they add an FAQ block, a price block or an image gallery to an existing page? If the answer to any of these is no, price in a permanent monthly development cost, because that is what you are buying.
The second consideration is rendering. Sites built as single-page applications can rank perfectly well, but they add a verification burden that never goes away: every release needs someone to confirm the content is still present in what the crawler receives. If nobody on the team will do that check, choose the simpler architecture. This is not a theoretical risk - it is the failure we see most often on modern rebuilds, and it usually surfaces two months after launch when someone finally asks why the new site has fewer indexed pages than the old one.
Third, check what the platform does to URLs when content is reorganised. Systems that silently change a URL when a page is moved between sections will generate a slow drip of broken links and lost signals that nobody attributes to the platform, because each individual instance looks like an isolated mistake.
Every redesign that changes URLs needs a one-to-one map from old to new. This is the single most common gap in a redesign budget, and the omission is rarely deliberate: the design agency assumes the SEO supplier will handle it, the SEO supplier assumes it is in the build scope, and nobody does it.
Three things prevent it. Name an owner in writing at kick-off. Budget the hours explicitly as a line item. And include a rule that no old URL redirects to the homepage — only to its equivalent page, or, if no equivalent exists, that is a signal the new site is missing a page rather than an excuse for a lazy redirect.
Alongside it, freeze a baseline before anything changes: clicks and impressions per URL for the last twelve months, positions for your query set, and indexing status. It takes half an hour, it is free, and it is the difference between diagnosing a post-launch dip and arguing about it.
Per-URL performance, positions and indexing status - free, ten minutes, and the only thing that makes a post-launch dip diagnosable instead of debatable.
Sign in to Semalt See Fast IndexingAt the information architecture stage, before any design work. Its job then is protecting the pages that generate business and flagging structural decisions that are expensive.
A well-run one dips 10-25% for four to eight weeks and recovers. A badly run one loses far more and often does not fully recover. The difference is inventory and redirects.
Modestly for rankings, considerably for conversion. Fix it, but for the revenue reason and in the templates that carry traffic.
Usually yes if it is present in the served HTML. Content that only loads on interaction is riskier and harder to verify - test rather than assume.
Plan the URL structure for it even if you launch in one language. Retrofitting a language prefix later is a migration; reserving it now is free.
A site that ranks is not a site with SEO applied afterwards. It is a site whose page inventory came from real search demand, whose templates have room for the things buyers ask about, and whose URL structure was decided once and left alone.
If a redesign is on your horizon, the two things to do this week cost nothing: write the page inventory from your own impression data, and freeze your current performance baseline. Both take an afternoon and both become impossible to reconstruct once the old site is gone.
If you want a second pair of eyes on wireframes before they are signed off - the cheapest moment to catch any of this - get in touch. Our initial audit is free and delivered within 48 hours.
Free analytics for Google Search, SERP rankings and AI answers - plus fast indexing for your new pages.
Sign in to Semalt semalt.comGet in touch for a free audit
