SEO for Web Designers: Build Sites Google and AI Can Find

Put a designer and an SEO in the same project and you usually get friction. The designer wants the page to feel a certain way. The SEO wants it to get found. Both are right, and the work only goes badly when neither one understands what the other is actually asking for.

I have built and run web properties since 2007, and most of the SEO problems I see still trace back to a handful of design decisions made early, before anyone was thinking about search. The good news is that almost none of it requires sacrificing the design. It requires knowing which choices have downstream cost. Here is what a designer needs to carry into every project.

You Are Now Building for Two Kinds of Reader

For most of the last decade, "will search engines find this" meant one thing: can Googlebot crawl and render the page. Google solved JavaScript rendering years ago. It runs a headless Chrome engine, executes your scripts, waits for content to load, and indexes the result. So a React or Next.js site that builds its content on the client can still rank.

That assumption breaks the moment you care about AI search. The crawlers behind ChatGPT, Claude, and Perplexity, GPTBot and ClaudeBot and PerplexityBot, request your page, read whatever HTML the server sends back, and leave. They do not run your JavaScript. They do not wait for components to mount or API calls to resolve. If your product copy, pricing, comparison tables, and FAQ answers only exist after the browser executes your bundle, those AI systems see an empty shell.

This creates a split most teams do not know they have. A client-rendered page can sit at position one on Google and earn zero citations across the AI answer engines, because the content was never in the HTML those crawlers read. People are running more of their research inside assistants every month, so that is a real channel to be missing from.

The fix is not to abandon your framework. It is to make sure the content that matters ships in the initial HTML response. Next.js, Nuxt, and Angular all do server-side rendering alongside client interactivity. Render the substance on the server, hydrate the interactive parts for humans. If you want to test a page the way an AI crawler sees it, disable JavaScript in your browser and reload. Whatever disappears is invisible to half the web's discovery surface.

Speed is a Design Decision, Not a Developer Cleanup Task

Google measures real user experience through three Core Web Vitals, and they are a confirmed ranking signal. The current "good" thresholds, documented on web.dev, are Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1, all measured at the 75th percentile of real visits. Fewer than 60 percent of sites pass all three, so this is winnable ground.

Every one of those metrics is shaped by design.

LCP is how fast your main element, usually a hero image or headline, finishes painting. Oversized hero images and heavy web fonts are the usual culprits. The old advice to keep your masthead short was really about this: stop spending the first second of the page on something that earns nothing.

CLS is visual stability. It is the layout jumping while it loads, the button that slides down right as someone goes to tap it. The single biggest cause is images, ads, and embeds without reserved space. Set explicit width and height on every image and iframe so the browser holds the slot before the asset arrives.

INP is responsiveness, how quickly the page reacts to a tap or click across the whole session. It replaced First Input Delay in March 2024 and it is the metric most sites fail, because fixing it means rethinking how much JavaScript runs on interaction. As a designer, the lever you control is restraint: every third-party widget, tracker, and animation library you add competes for the same main thread.

None of this means flat, lifeless pages. It means budgeting. Decide what the hero costs before you fall in love with it.

Build Navigation a Crawler Can Actually Follow

Drop-downs, fly-outs, and mega-menus are fine. The rule is that the links inside them have to be real, crawlable URLs in the markup. Build them with CSS and anchor tags, not navigation that only assembles after a script runs or a user interacts.

This is the same JavaScript problem from earlier, in a higher-stakes spot. If your primary navigation only exists once the client renders it, Google may still piece it together, but the AI crawlers will not, and you have hidden the map to your entire site from them. Mission-critical paths, category pages, money pages, product pages, should never depend on JavaScript to be discoverable.

Keep the link count on any page sane. Once you push past roughly a hundred links, you dilute how crawlers weigh each one and you make the page harder for people to use. A footer stuffed with two hundred links helps no one.

Headings and Structure Are How Machines Understand the Page

Put one H1 on every page. It can match the page title or differ from it, and you can style it however you like with CSS, so "the default H1 is ugly" was never a real objection. Use H2 and H3 to show the actual hierarchy of the content, not to hit a font size you wanted.

This matters more now because AI answer engines extract content by structure. When someone asks an assistant a question, the systems that answer well are the ones that found a clear heading matching the question and a direct answer underneath it. So write headings that read like the questions your audience actually asks, and answer them in the first sentence or two before you expand. This is the practical core of answer engine optimization, and it costs you nothing visually.

Semantic HTML carries the same weight. Use real <nav>, <main>, <article>, and <button> elements instead of a pile of styled divs. It helps screen readers, it helps crawlers, and the overlap between accessibility and SEO is large enough that doing one well tends to drag the other along.