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.

Images: Useful, but Never Load-Bearing for Meaning

Search engines and AI crawlers still cannot read what is inside an image. They infer it from the filename, the surrounding text, and the alt attribute. So never put words you need indexed inside a graphic, and write alt text that describes the image plainly. For your logo, that means the company name, not a list of keywords you wished you ranked for.

A few rules that pay off every time. Serve modern formats like WebP or AVIF. Size the file to the size it displays, do not ship a 2000px image into a 400px slot and let CSS shrink it. Use responsive images so phones get phone-sized files. Lazy-load anything below the fold, but never lazy-load your LCP image, since that delays the one paint Google is timing. And set explicit dimensions, which is the CLS fix from earlier doing double duty.

The Plumbing That Has Not Changed in Fifteen Years

Some of this advice predates most current frameworks and is still exactly right.

Pick one canonical hostname and make the site work only on that one. If both www.example.com and example.com resolve, you have split your own signals. Use a rel=canonical tag to point duplicate or near-duplicate URLs at the version you want indexed, but treat that as a backstop, not a license to create duplication you could have avoided.

Make sure a missing page returns a real 404 status code, not a 200 with a "not found" message on it. That second case is a soft 404 and it confuses crawlers. When you move or remove a URL, set a 301 redirect to the new home. Avoid 302s, meta refreshes, and JavaScript redirects for permanent moves, since they leak ranking value or get ignored.

Keep URLs short, lowercase, and readable, with words a human would recognize and no more than a few of them. /seo/web-designers/ beats anything with a query string and a session ID in it. Decide your URL structure before launch, because changing it later means managing thousands of redirects, and I have done that cleanup more times than I would like.

Give the site an XML sitemap, keep it current, and make sure it is reachable. For a small site it is optional. For anything with depth, it is the cheapest insurance you can buy.

Mobile and the Rest

Do not build a separate mobile site on an m. subdomain. That was a trap in 2013 and it is a worse one now that Google indexes the mobile version of your page first. Build responsive, serve the same URL to every device, and adjust the layout with CSS. One page, one URL, sized for the screen.

The Short Version

The design choices that hurt SEO are rarely about taste. They are about whether content reaches the machines that need to read it, whether the page loads and responds fast enough, and whether the structure makes the meaning obvious. Render your real content on the server. Budget for Core Web Vitals before you commit to the hero. Keep links crawlable and headings honest. Get those right and you can design however you want on top of them, and you will show up in Google and in the AI answers at the same time.

Frequently Asked Questions About SEO for Web Designers

Do Web Designers Need to Know SEO?

Yes. Most SEO problems trace back to design decisions made early, before anyone thought about search. The choices that matter most are how content is rendered, how fast the page loads and responds, and whether navigation and structure are readable by machines. None of it requires sacrificing the design.

Does JavaScript Hurt SEO?

Not for Google, which renders JavaScript before indexing. But the crawlers behind ChatGPT, Claude, and Perplexity (GPTBot, ClaudeBot, PerplexityBot) read the raw HTML and do not execute scripts. Content that only appears after the browser runs your bundle is invisible to those AI engines. Render important content server-side so it ships in the initial HTML response.

Can AI Search Engines Like ChatGPT Read My Website?

Only the content present in your page's HTML response. AI crawlers fetch raw HTML and leave without running scripts, so a client-rendered page can rank on Google and still earn zero citations in ChatGPT, Claude, and Perplexity at the same time. Server-side rendering closes that gap.

What Are Google's Core Web Vitals Thresholds?

Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1, each measured at the 75th percentile of real visits. All three are confirmed ranking signals.

How Many H1 Tags Should a Page Have?

One per page. Use H2 and H3 to reflect the real content hierarchy. AI answer engines extract by structure, so headings that match the questions people ask, with a direct answer underneath, are far more likely to be cited.

Should I Build a Separate Mobile Website?

No. Avoid m. subdomains. Google indexes the mobile version of your page first, so build responsive, serve one URL to every device, and adjust the layout with CSS.