toolkit

Scenario · The bigger jobs

Build a new site from scratch

A new practice, or a rebuild with no existing site to migrate from.

A brand-new site is the one moment with no old mess to work around, which makes it the cheapest possible time to get the fundamentals right — measurement installed everywhere, one place for the practice's name and contact details, every page checked before it ever goes live. This provides a starting structure instead of a blank folder, plus every check needed to grade the finished site — search readiness, accessibility, speed, local details — before launch, when every fix is still free.

What to ask for

Static-site boilerplateStatic-site boilerplate generator — writes robots.txt, sitemap.xml, 404.html, and _redirects for a site with no server behind it.Cloudflare deploy surface checkVerifies a live Cloudflare Pages deploy for the six traps invisible to every check that only reads HTML: a Content-Security-Policy header silently dropped because its _headers line ran over Cloudflare's length limit; a served asset over 25 MiB, which hard-rejects the whole deploy; the deployed HTML rewritten by Auto-Minify so a byte-parity comparison drifts against a transform nobody made; a stale edge-cached alias serving the previous bundle for up to 24h after a redeploy; declared _headers/_redirects rules that were written but never confirmed live; and an Access-gated preview reachable on its unprotected deployment alias even though the project alias is gated.On-page SEOOn-page SEO scan — reads a page's delivered HTML and checks the head, meta and heading signals search engines use: title presence and length, meta description, rel=canonical, meta robots (noindex), Open Graph tags, viewport, html lang, and exactly one H1, plus a structured-data summary.Structured data (schema)Structured-data audit — checks a page's JSON-LD against a per-type rubric: valid JSON, a schema.org context, and the required and recommended properties that gate rich results for Organization, WebSite, Article, Product, LocalBusiness, BreadcrumbList, FAQPage, Event, Recipe and more.Accessibility (a11y)Accessibility scan for a live page — runs axe-core (Deque) across device presets and scores the page against WCAG, returning an absolute PASS / REVIEW / FAIL verdict plus a self-contained HTML report grouped by impact.Performance (Core Web Vitals)Core Web Vitals and performance scan for a live page.Local SEO (NAP)Local SEO / NAP audit — reads a page's delivered HTML and checks the local-search signals a business page lives or dies by: LocalBusiness structured data with a complete Name-Address-Phone, a phone and street address on the page, NAP consistency between the schema and the visible page (a mismatched phone fails the page), and Google Business Profile readiness — opening hours, geo coordinates, an embedded map.

See it work

A real run of Static-site boilerplate:

PASS — toolkit-tests.pages.dev · staging (noindex) · 4 URL(s) in sitemap
  robots.txt:   ./deploy/robots.txt
  sitemap.xml:  ./deploy/sitemap.xml
  404.html:     ./deploy/404.html
  _redirects:   not generated (no --map given)

  report: ./out/static-site-boilerplate-static-site-boilerplate.html
  json:   ./out/static-site-boilerplate.json

The captured report, exactly as a run hands it to a client —open the full report ↗

A new build is the one situation with no legacy to work around, which makes it the only chance to get the defaults right for free. Every standard adopted here costs nothing now and is a migration later.

  1. Scaffold the project rather than starting from a blank folder. The boilerplate gives a static-site skeleton with the structural decisions already made. A hand-rolled start is where a site acquires its first inconsistency.
  2. Get the measurement and the identity in before the content. Analytics and tag manager on every template including the confirmation pages, and the practice’s name, address and phone in one place that every page reads from. Retrofitting either is the most common avoidable rework on a new build.
  3. Build the pages. Each new page follows the new-page procedure — briefed, then graded before it goes live.
  4. Grade the whole thing before launch, not after. On-page SEO across every page, structured data for the practice and its services, accessibility, and performance. Nothing links here yet and nothing is indexed, so every finding is free to fix.
  5. Check the local signals. Name, address and phone consistent across the site and matching what the Business Profile will say. A new site is the easiest possible time to make these agree, and it never gets easier.
  6. Confirm the deploy surface is what you think it is. The deploy check reports what is actually serving versus what was last built — a new project’s first real deploy is the one most likely to be serving a stale or partial build.
  7. [manual] Launch, then re-run the grades against the live URLs. Staging and production differ in ways that matter — headers, caching, redirects — and the record should be of the site as visitors get it.

No predecessor is the advantage

The pre-live gate for a rebuild spends most of its effort proving nothing was lost. Here there is nothing to lose, so the effort goes into standards instead: measurement everywhere, one source for the practice’s details, every page graded before anything points at it.

What this does not cover

Design, content and the commercial decisions. This is the scaffolding and the launch gate: a project skeleton that starts correct, and the checks that say it is fit to go live. It cannot tell you the site is any good, and it deliberately does not cover replacing an existing live site — that has a predecessor to compare against and its own pre-live gate.

← All scenarios