Web development and SEO: the five build time decisions, and the handover checklist that goes with them

Five decisions made during a build decide whether a site can rank at all: how pages are rendered, how URLs are shaped, which status codes the server returns, what the performance budget is, and how crawling is controlled. Every one of them is cheap to get right before launch and expensive to change afterwards, because changing a URL or a rendering model later means a migration. The developer owns those five. Whoever owns search owns titles, content, internal links and reporting. The handover is a written list of which side owns what, signed off before the first sprint rather than after the traffic drops.

This page covers the build time decisions and the handover between a dev team and whoever owns search. For the ongoing content and link work that follows launch, see guides to internal linking and to writing for search.

Rendering: the decision that is hardest to reverse

Google crawls, then renders, then indexes. The Google guide to JavaScript SEO basics states that Googlebot queues every page returning a 200 status for rendering unless a robots meta tag or header says otherwise. So JavaScript rendered content can be indexed. The question is how much you want to depend on that for pages that pay the bills.

Approach	What the crawler gets first	Best fit
Static generation	Complete HTML, instantly	Marketing pages, blogs, docs, anything that changes on a deploy
Server side rendering	Complete HTML per request	Catalogues, listings, anything personalised or frequently updated
Client side rendering	An empty shell plus a script bundle	Logged in application screens that are not meant to be indexed

The rule of thumb that keeps teams out of trouble: any URL you want to rank should ship its main content, title, meta description and canonical link in the first HTML response. Four specifics from the same Google guide are worth putting in your definition of done:

• Use the History API for navigation, not URL fragments. A route behind a hash is not a separate URL to a crawler.
• If you inject a canonical with JavaScript, make sure it is the only one on the page. Two canonical tags is a coin toss you do not need.
• Return real status codes. For a client side app, either redirect to a server side 404 or inject a noindex tag, so a missing product does not become a soft 404.
• Fingerprint asset filenames so a content change produces a new URL and nobody is served a stale cached bundle.

URLs you will not have to migrate

The Google guidance on URL structure is short and concrete. Use readable words rather than long ID numbers. Use hyphens, not underscores, to separate words. Percent encode non ASCII characters in links. Separate parameters with an equals sign and an ampersand, and drop parameters that do not change the content. Add four house rules of your own:

• Lowercase only, enforced by a redirect, because two cases of the same path are two URLs.
• Pick a trailing slash convention and redirect the other form. Either is fine. Both at once is not.
• One canonical URL per piece of content, with every other version redirecting or pointing at it. The Google note on consolidating duplicate URLs covers the options.
• Do not put the publication date or the stack in the path. Both become reasons to migrate later.

Status codes, in the words a developer can test

• 200 for a page that exists and has content. A page that renders "no results found" and returns 200 is a soft 404, and it dilutes the site.
• 301 for anything that has moved for good. The Google page on redirects and Google Search explains how each type is treated.
• 302 only for something genuinely temporary, which is rarer than most codebases suggest.
• 404 or 410 for gone, and let it be gone. Redirecting every dead URL to the home page is worse than a clean 404.
• 503 during planned maintenance, so a crawler comes back instead of recording an error page.
• Zero chains. One hop from old URL to final URL. Test it in CI with a list of your top two hundred URLs.

A performance budget you can fail a build on

Core Web Vitals give you three numbers to hold. The web.dev reference sets the good thresholds at Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of page loads and split by mobile and desktop. Put those in the build pipeline, measured on a throttled mobile profile, and make the build fail when a template crosses them.

• Find the LCP element per template and make it the one thing that loads first. Usually a hero image or a headline.
• Reserve space for every image, advert and embed with width and height attributes, which removes most layout shift at the source.
• Lazy load below the fold only. Lazy loading the LCP image makes the score worse.
• Budget the JavaScript per template in kilobytes and review it at every pull request. Nobody has ever reduced a bundle after launch without a fight.
• Measure field data, not just the lab. PageSpeed Insights shows both for a URL, and Search Console reports the field data across templates.

Crawl control, set once and documented

• robots.txt controls crawling, a noindex meta tag controls indexing. They are not interchangeable. A URL blocked in robots.txt can still appear, because the crawler never reached the noindex. The Google robots.txt introduction is the reference.
• Never block the JavaScript and CSS that the page needs in order to render.
• Generate the XML sitemap from the database, containing only canonical, indexable, 200 returning URLs. The Google guide to building a sitemap covers the formats.
• Keep staging out of the index with HTTP authentication, not robots.txt alone.
• On a large catalogue, watch faceted navigation. Filter combinations generate near infinite URLs, and the Google guide to managing crawl budget explains why that matters once a site is big.
• Ship structured data as part of the template, not as a plugin afterthought. Start from the Google introduction to structured data.

The handover checklist

Item	Owner	Done means
Rendering model per template	Development	Main content in the first HTML response for every indexable template
URL patterns and redirect map	Development	Lowercase, hyphenated, one canonical form, old to new in one hop
Status code behaviour	Development	No soft 404s, no chains, 503 for maintenance
Performance budget in CI	Development	Build fails when a template crosses the thresholds
robots.txt, sitemap, structured data	Development	Generated from the database and validated on deploy
Editable title and meta description per page	Development builds, search owns	Editable in the CMS without a deploy
Search Console and analytics	Shared	Both properties verified before launch, not after
Titles, content, internal links	Search	Written against a target query per page
Post launch monitoring	Shared	Indexing report and Core Web Vitals reviewed weekly for the first month

Two launch day rules save the most pain. Verify Search Console before launch, so you have a baseline to compare against. And keep the redirect map in version control, because the person who needs it in eighteen months is not the person who wrote it.

The web development and SEO questions worth an answer

Does a JavaScript framework hurt rankings?

No, when the content is rendered server side or statically and the URLs behave. Frameworks run into trouble when important content only appears after a client side fetch, and when routes hide behind fragments instead of real paths.

Who should own SEO on a dev team?

Give the five build time items to the developer who owns the templates, and give titles, content and links to whoever owns search. Write it down. Most launch failures are an ownership gap, not a skill gap.

How early should SEO be involved in a build?

At the point the URL structure and the templates are being designed. That is the hour that buys the most, because both are costly to change once content exists.

Do Core Web Vitals affect rankings?

Page experience is part of how Google assesses pages, and the practical case is simpler than the ranking question: a fast template converts better and gets crawled more efficiently. Hold the thresholds because they are good engineering.

What is the single most common technical mistake at launch?

Shipping the staging robots.txt with a site wide disallow, or launching without the redirect map applied. Both are caught by one checklist item and both cost weeks when missed.

How do I prove a template renders correctly for Google?

Use the URL Inspection tool in Search Console and read the rendered HTML it reports for a live URL. If your main content and canonical link are in there, the template is doing its job.

One more thing the build affects

Clean HTML, real status codes and a fast server do something beyond Google rankings now. When a buyer asks ChatGPT, Gemini, Perplexity, Claude or Google AI Overviews for suppliers in your category, the answer is assembled from pages those systems can fetch and parse, and a page whose content only appears after a client side fetch gives them very little to work with. The same build decisions that make a page indexable make it quotable. It is worth asking, once the site is live, what those assistants actually say when somebody describes your product without naming you, because the answers differ between them and most teams have never looked. AI Knows Us runs that check and reports which pages get cited.