SEO Requirements for a New Website: The Spec to Hand Your Builder Before They Start

By Christoph Olivier, Founder, CO Consulting

Last reviewed: July 2026

SEO requirements for a new website are the written clauses you hand your developer or designer before a single page is built, turning search visibility into a contractual acceptance criterion instead of a post-launch scramble. This is not the tick-list you work through yourself after the site is live. It is the spec that defines “done,” names who owns each line, and gives you the right to reject the build if it fails. I have watched three six-figure rebuilds ship on time, on budget, and dead in Google because nobody wrote these clauses into the statement of work. Below is the exact spec I now attach to every build contract, grouped by owner so your team can accept or reject each item at sign-off.

Why SEO requirements belong in the build contract, not a launch checklist

Put SEO in the requirements spec because after launch you are negotiating a change order; before launch you are enforcing a contract. A checklist you run yourself finds problems when the invoice is already paid and the developer has moved on. A requirements spec makes each item a condition of acceptance, so a missing canonical or a live noindex is the builder’s cost to fix, not yours.

The most expensive line I see gets skipped for the same reason every time: the person writing the brief assumes the agency “just does SEO.” They do not, unless you wrote it down. Structure, crawl control, and metadata get set at build time and are painful to retrofit. Contentful, code-level decisions like URL patterns and heading logic are cheap on day one and a rebuild by month six.

The table below shows the split that trips most founders. If you only ever had a checklist, you were doing the builder’s QA for free.

For the DIY side of this, our SEO checklist for new websites is the companion piece you run yourself after handoff. This page is what you send before anyone writes code.

How to write SEO requirements into a build brief

Write each requirement as a testable clause with an owner and a pass condition, then attach it as an appendix to the statement of work. A good requirement reads like “All indexable pages must return HTTP 200, expose exactly one H1, and carry a self-referencing canonical, verified by crawl before sign-off,” not “make the site SEO-friendly.” Vague briefs produce vague builds.

1. State the requirement as one sentence with a measurable pass condition.
2. Name the owner: developer, infrastructure, or content team.
3. Name the verification method: crawl, Lighthouse run, or manual check.
4. Set the milestone: staging review, pre-launch, or launch day.
5. Make acceptance conditional on all clauses passing.

Assign owners explicitly. When “SEO” is everyone’s job it is nobody’s job. In practice, developers own crawl and code, infrastructure owns redirects and HTTPS, and your content team owns titles, headings, and internal links. If you are also planning the wider search program around this, our complete guide to Google SEO in 2026 covers the strategy the spec exists to protect.

The technical SEO requirements to specify for developers

Developer requirements govern how the site is structured, crawled, and rendered, and they are the clauses that cost the most to fix after launch. Specify crawl control, indexation rules, URL patterns, rendering, and Core Web Vitals as pass or fail conditions verified on staging. These are code-level decisions; get them wrong and you are paying for a partial rebuild.

• Remove the staging noindex before launch. Most CMS platforms noindex a site in development. Ship with it live and you can sit invisible for months. Require a documented launch step that flips it and a post-launch crawl proving it is gone.
• Editable robots.txt and meta robots without a developer ticket. The spec must name which page types are indexable and which are not, and give the content team control.
• Clean, lowercase, hyphenated URLs editable from the CMS, no session IDs or default query strings.
• One canonical host. www and non-www, HTTP and HTTPS, all resolve to a single canonical URL via 301. Failing this creates duplicate content that splits link equity.
• Server-side rendering or prerendering for any JavaScript framework, so primary content and links exist in the raw HTML.
• An auto-generated, submittable XML sitemap that updates on publish and excludes noindexed URLs.
• Core Web Vitals pass on mobile: LCP under 2.5s, INP under 200ms, CLS under 0.1, verified with Lighthouse and PageSpeed Insights on real templates, not the homepage alone.
• Same content on mobile and desktop. No content hidden behind “read more” that mobile users must tap to reveal, given mobile-first indexing.

For the deeper engineering version of this list, our technical SEO checklist for founders expands each clause. When you cite Core Web Vitals thresholds to a builder, the field data in our SEO statistics library makes the case that speed is a ranking input, not a nicety.

Content and metadata requirements to specify for the designer and content team

Content-side requirements control what search engines and AI engines read on the page, and they are cheap to enforce at design time. Specify heading hierarchy, editable title and meta fields, structured data, image handling, and internal linking as template-level guarantees. If the CMS cannot edit a title tag, you have already lost.

• Per-page editable title tag, meta description, and canonical on every template, including archives and taxonomy pages.
• Logical heading hierarchy: exactly one H1 per page, H2 and H3 for structure, headings used for meaning and not styling.
• Schema markup baked into templates: Organization, Breadcrumb, Article, and Product or LocalBusiness where relevant, in JSON-LD. In 2026 structured data feeds both classic rich results and AI answer engines.
• Image requirements: editable alt text, next-gen formats (WebP or AVIF), lazy loading, and explicit width and height to prevent layout shift.
• Internal linking that a human controls: in-body contextual links with descriptive anchors, plus breadcrumb navigation.
• Open Graph and Twitter card fields editable per page for clean social and AI-preview rendering.

Structured data and clear headings are also what get you quoted in AI Overviews and ChatGPT answers, which is why our guide to AI search and GEO in 2026 treats them as non-negotiable spec lines, not extras.

Analytics, security, and launch-day requirements

Infrastructure requirements make the site measurable and safe from the first hour it is live. Specify HTTPS everywhere, analytics and Search Console setup, and a launch-day verification pass as explicit deliverables. These are the items builders quietly assume someone else will do.

• HTTPS on every page and asset, with mixed-content warnings resolved. Google treats security as a ranking input.
• GA4 installed once, with no duplicate tags from a parallel Tag Manager container.
• Google Search Console verified, sitemap submitted, property confirmed on launch day.
• A redirect map if this replaces an existing site: every old indexed URL 301s to its closest new equivalent, no chains, delivered as a spreadsheet.
• A launch-day verification pass: crawl the live site, confirm no stray noindex, robots.txt is not blocking key paths, SSL is valid, and PageSpeed passes on core templates.

A skipped redirect map is the single most common way a redesign torches years of rankings overnight. Write it into the contract as a named deliverable with a due date before launch, not a nice-to-have.

A worked example: turning one line into an enforceable clause

Here is the transformation I run on every brief, using the most-skipped requirement. It shows why a spec clause survives a dispute and a checklist item does not.

Run that rewrite on every line above. The pattern is always the same: a measurable pass condition, a named owner, a verification method, and a milestone. That is the whole discipline, and it is why buyers who write specs pay less and rank sooner. If you would rather hand this to a partner who builds to these standards, our web development SEO services ship against exactly this spec, and a consultation is the fastest way to pressure-test your brief before you sign a contract.

Frequently asked questions

What are SEO requirements for a new website?

SEO requirements for a new website are the written, testable clauses you give a developer or designer before the build, covering crawlability, URLs, metadata, structured data, speed, and redirects. They act as acceptance criteria in the contract, so search visibility is a condition of “done” rather than a post-launch fix you pay for twice.

How is an SEO requirements spec different from an SEO checklist?

A checklist is a task list you work through yourself after the site exists. A requirements spec is a set of contractual clauses you hand your builder before they start, each with an owner and a pass condition. The checklist finds problems after payment; the spec makes the builder fix them before sign-off, at their cost.

Who should own each SEO requirement during a build?

Assign owners explicitly so nothing falls through. Developers own crawl control, URL structure, rendering, and Core Web Vitals. Infrastructure owns HTTPS, redirects, and analytics setup. Your content team owns titles, headings, internal links, and image alt text. Unassigned requirements are the ones that quietly fail at launch.

What is the most commonly missed SEO requirement in a new build?

Two tie for first. A staging noindex tag shipped to production keeps the site invisible for months, and a missing redirect map on a redesign 301s nothing, so old rankings vanish overnight. Both belong in the spec as named, verified launch-day deliverables with a pass or fail check.

Should SEO requirements go in the contract or a separate document?

Put them in the contract, usually as an appendix to the statement of work, and make acceptance conditional on them. A separate, non-binding document has no teeth. When the clauses are part of the SOW, a failed crawl or a missing canonical becomes the builder’s obligation to fix before you sign off and pay.