SEO and Website Design: The Design Decisions That Decide Whether You Rank

SEO belongs in the design phase, not the launch checklist. The decisions that determine whether a site ranks (information architecture, URL structure, heading hierarchy, how much of your value proposition exists as real text, image weight, where internal links live) are all made in the design file, weeks before anyone writes a meta description. By the time a site is built, most of its SEO ceiling is already set.

This is why a redesign can quietly cost you traffic. A gorgeous design can underperform the plain site it replaced. Not because the design is bad, but because nobody in the room was asked what the design would do to search.

Why does SEO have to happen during design?

Because the expensive SEO problems are structural, and structure is a design output. You can fix a thin meta description in ten minutes. You cannot fix a navigation that flattened forty pages into six, or a homepage where the entire proposition is a rendered image, without redoing the design.

The usual sequence is: strategy, design, build, then hand the finished thing to an SEO team to "optimise." What that team receives is a set of constraints, not a page. They can adjust titles and alt text. They cannot invent the content depth the design left no room for. This is the handoff tax: every department optimises for its own success metric, and the site pays.

Strategy comes before pixels. That is not a slogan about brand workshops. It means the page inventory, the URL map and the keyword-to-page assignment exist before the first artboard.

How should you plan site structure and URLs?

Plan them before design starts: give every page one job and one query cluster, decide URLs before the build, and map every existing URL to its new home with a 1:1 redirect.

Your sitemap is an SEO document that happens to look like a nav menu. Every page you merge in the name of simplicity is a page that stops competing for its own query. Every URL you change without a redirect is equity thrown away.

What to decide during design:

• One page, one job, one query cluster. If two pages target the same intent, they compete with each other. If one page targets four intents, it ranks for none of them well.
• Depth, deliberately. "Simplify the nav" is a design instinct that often deletes ranking pages. Keep the depth, change how it's surfaced.
• URLs decided before build, not after. Short, readable, stable. Changing a URL later means a redirect, and a redirect chain is a slow leak.
• A 1:1 redirect map for every existing URL if this is a redesign. Redirecting everything to the homepage is the single most reliable way to lose rankings you already earned.

Run this against real data. Pull the pages currently earning organic traffic and links before anyone proposes deleting them. Designers should not be guessing which pages matter.

Does heading hierarchy actually matter for SEO?

Yes, and it breaks in design more often than in code. Headings tell search engines and AI systems how a page is organised. When headings are chosen for size rather than structure, that map goes missing.

The common failure: a design system with styles named Display, Heading, Subhead, Body. A designer picks Display because the text should be big. It ships as an H1. Now the page has four H1s and no logical outline. Or the opposite: a genuinely important section is styled small, so it's built as a paragraph, and the page's key topic is invisible as structure.

Fix it in the design system itself. Separate semantic level from visual size. A component should be able to be an H2 that looks small, or an H3 that looks large. One H1 per page, describing the page. H2s that name real sections. No skipped levels. This costs nothing at design time and is tedious to retrofit.

How much of your page is real text?

Text baked into an image is text search engines and AI answer engines cannot read. Alt text is a caption, not a substitute for content.

This is the most common expensive mistake in SEO web page design. The hero says everything that matters about the business, and it's a flattened graphic, or a canvas animation, or copy so short it carries no information. The page looks confident and says almost nothing indexable.

Three checks before a design is approved:

• Would someone reading only the selectable text understand what this page offers?
• Does the page have enough real content to answer the query it targets, or is it a mood board with a button?
• Is critical copy rendered as HTML, not as an image, a video overlay, or content that only appears after a script runs?

You can have visual ambition and readable text. It just has to be a requirement before the layout is made, not a complaint afterwards.

How does design affect page speed?

Performance is a design budget, and someone has to own it during design. Google measures loading, interactivity and visual stability through Core Web Vitals, and a design can blow that budget before a developer touches it.

Set the budget at design time. Decide how many custom fonts the site gets. Decide whether the hero is a video, and what it costs. Decide the maximum number of full-bleed images per template. Modern formats, correct dimensions, explicit width and height so the layout doesn't shift while loading: these are cheap when planned and painful when discovered during QA with a launch date attached.

The honest tradeoff: some visual ideas cost more than they return. A team where design and engineering are the same team can price that in a conversation. A team with a handoff finds out at the end.

Where should internal links live in the design?

Internal links should be a component, not an afterthought. They distribute authority, define topical relationships and give crawlers paths to your deeper pages. Bolted on later, they look like it: a lonely "related posts" strip nobody designed.

Build the mechanism into the templates: contextual links inside body copy, a related-content pattern that pulls genuinely relevant pages, breadcrumbs on deep pages, and footer links that are curated rather than a dump of everything. Then make sure every page you care about is reachable from somewhere prominent. Orphan pages are usually created by a nav simplification, and nobody notices until traffic doesn't arrive.

How do you design pages AI answer engines can cite?

Give each page a clear heading outline, open every section with a direct answer, and state facts as real text that still makes sense when it is lifted out of the page.

AEO (answer engine optimisation) means structuring content so tools like ChatGPT, Perplexity and Google's AI Overviews can understand, trust and cite it as a source. Design decides whether that's possible.

The design-side inputs are simple. A clear H2/H3 outline. Sections that open with a direct answer before elaborating. FAQ blocks with self-contained answers, backed by schema markup. Facts stated as text rather than implied by a diagram. Content that stands on its own when extracted from the page, because that is exactly how it will be used.

Schema markup is part of this too, and it's easier when the design already reflects the structure the markup describes: a real FAQ section, a real service page, a real article.

The pre-build checklist

Before a single page gets designed, have these agreed:

• Page inventory with one target query cluster per page
• Final URL structure, plus a 1:1 redirect map if it's a redesign
• Heading hierarchy rules in the design system, semantics separated from size
• Minimum real-text requirements per template
• Performance budget: fonts, image weight, hero media
• Internal linking components in the template set
• Structured content patterns and schema for the pages you want cited
• Analytics and Search Console configured before launch, not after

None of this is exotic. It's just usually nobody's job. At Urest we run design, development and growth as one team, because these decisions can't survive being passed between departments. A website's job is to work, not just to look finished.

Frequently asked questions

Can you add SEO to a website after it's built?

Partially. Metadata, alt text, schema markup and content edits can all be added post-launch. What cannot be retrofitted cheaply is information architecture, URL structure, heading semantics baked into a design system, and performance problems caused by heavy design choices. Those require rebuilding, which is why SEO belongs in the design phase.

Why did my traffic drop after a website redesign?

The most common causes are URL changes without 1:1 redirects, pages deleted during a nav simplification, heading structures rewritten so search engines no longer understand the page topic, metadata not carried over, and pages accidentally launched with noindex rules inherited from staging. Almost all of these are preventable if SEO is involved before the design is finalised.

Does website design affect SEO rankings directly?

Design affects rankings through its consequences rather than aesthetics alone. Layout determines heading structure and how much readable text a page contains. Visual choices determine page weight and Core Web Vitals scores. Navigation design determines crawl paths and internal link distribution. Search engines do not judge taste, but they do measure everything design decides.

What is AEO and how does it relate to web design?

AEO, or answer engine optimisation, is structuring content so AI tools like ChatGPT, Perplexity and Google's AI Overviews can understand, trust and cite it as a source. It relates to design because extractability depends on structure: clear heading hierarchies, sections that open with direct answers, self-contained FAQ blocks and schema markup. A page whose key claims live inside images or animations cannot be cited.