SEO-friendly web design: building a site Google can actually read

Every week, somewhere in Sydney, a business launches a gorgeous new website and watches their Google traffic fall off a cliff. Not because Google dislikes good design — because the redesign quietly broke the things Google was relying on. The old URLs vanished without redirects. The content moved inside JavaScript that crawlers struggle with. The headings became styled divs that mean nothing to a machine.

"SEO-friendly web design" isn't a design style. It's a set of engineering decisions, most of them invisible, that determine whether your site is legible to the systems that send you customers.

The big one: is your content real HTML?

Modern sites are often built as JavaScript applications: the page that arrives from the server is an empty shell, and the visitor's browser assembles the content afterwards. Humans never notice. Crawlers do. Google can execute JavaScript, but it does so later, less often, and less reliably — and other systems that matter (social previews, AI assistants, smaller search engines) often don't bother at all.

The fix is server rendering or pre-rendering: the page arrives with its content already in the HTML. It's how we build every site we ship — including this one. The test takes ten seconds: view your page's source (not "inspect", the raw source) and search for a sentence from the page. If it's not there, Google is being asked to do extra work to see you — and it doesn't always do it.

Structure that machines can follow

• One H1 per page, saying what the page is. Headings are the machine-readable outline of your content, not font sizes.
• Descriptive URLs. /services/hot-water-repairs beats /page?id=47. URLs are read by humans in search results too.
• Real links. Navigation built from clickable divs with JavaScript handlers is invisible to crawlers. Links must be actual links.
• Every page reachable within three clicks. Orphan pages — reachable only via search bar or sitemap — rank poorly because internal links are how Google judges what you think matters.
• Images with dimensions and descriptions. Alt text and explicit sizes: accessibility, image search, and layout stability in one move.

Speed is a design decision, not a plugin

Core Web Vitals — Google's speed and stability measurements — are ranking signals, but more importantly they're conversion signals: slow pages lose people before the pitch. The causes are nearly always decided at design time: a 4MB hero video, a font family in six weights, a carousel library loaded for one testimonial slider.

The discipline is choosing what earns its bytes. Beautiful and fast are not in tension; heavy and lazy are.

Redesigning? Protect what you’ve earned

If you already rank for anything, a redesign is surgery on a functioning organ. The non-negotiables:

• Map every old URL to its new home with permanent (301) redirects — before launch, not after the traffic drops.
• Keep the pages that rank. Check Search Console for what earns traffic today; don't delete a workhorse page because it doesn't fit the new sitemap.
• Benchmark before, monitor after. Record rankings and traffic pre-launch, watch daily for a month post-launch, and treat any drop past two weeks as a defect to diagnose, not a mystery to accept.

What to ask your web designer

Three questions separate builders who understand search from builders who make pretty brochures: "Will my content be in the HTML the server sends?" "What's your redirect plan for my existing URLs?" and "What will this score on Core Web Vitals?" Anyone doing this properly answers all three without flinching.

A website is the one asset every other channel points at — SEO, paid media and tracking all stand on it. Build it so the machines can read it, and everything downstream gets easier.