What every site ships with. A checklist you can hold us to.
Still Fox, a Seattle practice, builds websites that meet the specification below and hardens existing sites to the items marked for hardening.
The specification
A promise says a site will work. A specification lists what the site contains and names the check that proves each item, so a buyer can ask for the result of any check and see it. Every rebuild meets every item below. Every hardening meets the items tagged Hardening or Both, on the pages it changes. Nothing here guarantees a ranking, a mention or a lead: the specification covers what a website controls, and the before-and-after reading reports the rest with its run count.
Each item has a name, a definition, the check that verifies it and when the check runs. The tag says where it applies: Rebuild, Hardening or Both.
-
Search and user crawlers are let in. Applies to: Both
Every search and user crawler can read every page, in robots.txt and at the CDN or firewall in front of the site, because a site that blocks OAI-SearchBot is out of ChatGPT search answers.
How it is verified: we read robots.txt for OAI-SearchBot, PerplexityBot, Claude-SearchBot, Meta-WebIndexer, Googlebot and Bingbot, then fetch the home page with each one's user agent. A 403 or a challenge page counts as a block. The check runs before and after the work and, in the care plan, every week, with the result in the monthly note.
-
The text is in the HTML. Applies to: Both
The words on every page are in the HTML a crawler fetches, because the last public test of AI crawlers, in December 2024, found that none ran JavaScript.
How it is verified: the readiness check compares the text in the raw HTML with the text after the page renders and flags a page where the raw text is under 0.8 of the rendered text. On a hardening, a flagged page gets a server-rendered version or a static mirror. The check runs before and after the work.
-
No client JavaScript by default. Applies to: Rebuild
A rebuilt site loads no JavaScript by default, and each exception, such as a booking tool, is documented one at a time.
How it is verified: on every build, the structure check fails on any script except the one structured-data block, and the speed test fails on any script request or third-party request. A documented exception is listed in the site's check configuration.
-
The first sentence says who, what and where. Applies to: Both
The first sentence of every page names the business, what the page covers and the place, in about 150 characters, because Claude's web search tool returns at most 150 characters of cited text per source.
How it is verified: the structure check reads the first sentence of every page for the business name, a place and the page subject. A sentence over 150 characters is flagged and one over 220 fails the build. On a hardening, the pages it adds are read against the same rule.
-
One page for each service, location and person. Applies to: Both
Each service, each location and each person has a page of its own, not a section of a longer page.
How it is verified: the site is generated from the entity record, with one page for each service, location and person in it, and the structure check confirms that every page is in the sitemap and every internal link resolves. A hardening adds the service and location pages that are missing.
-
One record behind every page. Applies to: Both
The name, address, phone and hours are the same on every page, because one record supplies all of them.
How it is verified: the page text, the structured data and the lawyer's sign-off sheet are generated from the same entity record, so they cannot differ. On a hardening, a consistency pass compares the name, address, phone and hours across the site and lists each mismatch, with a gap list for the directory profiles. The care plan repeats the directory comparison every third month.
-
WCAG 2.1 AA, self-evaluated. Applies to: Both
Every page meets the web accessibility standard WCAG 2.1 level AA, as evaluated by the practice itself, with no overlay widgets.
How it is verified: the axe testing tool runs on every page at 1280 and 375 pixels wide and must report zero violations, then a manual pass covers keyboard use, focus, link purpose, reading order and forms. The result is published as a self-evaluation on the accessibility page, with the date and a contact. It runs on every build and, in the care plan, every third month. On a hardening, the pages it changes pass and a defect list covers the rest.
-
A Lighthouse budget. Applies to: Rebuild
Every page loads fast and light enough to pass a written budget, measured with the Lighthouse tool on its mobile profile.
How it is verified: performance, best practices and SEO score 0.95 or higher and accessibility scores 1.0, with largest contentful paint at 1500 milliseconds or less, layout shift at 0.02 or less and total blocking time at 50 milliseconds or less. No page makes a script request or a third-party request, and every page weighs under 150 KB. The check runs on one page of each type on every build and on every page before launch.
-
The indexing basics are in place. Applies to: Rebuild
Every page has its own title, its own description and a canonical link, the site has a sitemap and an IndexNow key, and verification slots are ready for Search Console and Bing Webmaster Tools.
How it is verified: the structure check fails on a missing or duplicate title or description, a missing canonical, and a sitemap that does not match the pages. The launch check refuses to pass without both verification codes and an IndexNow key, and the IndexNow ping goes out once the site is live.
-
Structured data is included and never sold. Applies to: Rebuild
Every rebuild includes structured data (JSON-LD) at no charge, and the practice does not sell it as a way to rank, because the one controlled test found no citation lift.
How it is verified: the block on each page uses the LocalBusiness or LegalService, Attorney, Person and FAQPage types, is generated from the entity record, and is checked for valid syntax and vocabulary with the Schema Markup Validator and for rich-result eligibility with the Rich Results Test. Its data must match the visible text. The check runs on the preview, and the invoice has no line for it. The method page grades the evidence behind every tactic.
-
The client owns it from day one. Applies to: Both
The client owns the domain, the content and the repository from day one, and every account is created in the client's name.
How it is verified: the accounts are created under the client's name at intake, and the practice and any partner agency hold member seats, not ownership. The hand-off package lists the owner logins, how edits are requested, the accessibility statement text and the exit procedure. On exit the practice removes its seat and the site keeps running. On a hardening, the client keeps the site and its accounts.
-
A lawyer signs off the pages. Applies to: Both
On every law-firm build a lawyer signs off every page before launch, and again on any changed page, because Washington RPC 7.1 governs lawyer advertising and the lawyer stays responsible under RPC 5.3 and 8.4(a).
How it is verified: the kit prints a sign-off sheet with every page's text, the entity facts, the advertising notice and signature lines. The launch check fails until the sign-off is recorded with the lawyer's name, bar number and date. A changed page waits for a new dated approval before it publishes. On a hardening, the pages it adds or changes go through the same step.
-
A before-and-after reading. Applies to: Both
Every rebuild and hardening comes with a reading of what AI assistants say about the business before the work and the same reading after it.
How it is verified: a fixed set of buyer questions, each asked several times, on the official search APIs of OpenAI, Perplexity and Anthropic. The reading reports the share of answers that name the business with a 95% interval, the pages the assistants cite and every factual error against the entity record, and it names the surface and the run count. The before reading is taken before any change. The consumer apps are not measured, and their answers can differ from the API's.
What is not in the specification
- Logo and photography. The client or the agency supplies them.
- New content the business does not have. A new practice area, or a bio for a person with no material, is a change order at a flat fee.
- A blog or a content management system. The site is static pages. Posts are edits under the care plan or a change order.
- Client-side analytics and chat widgets. Booking tools and tracking pixels are out too. Any script breaks the no-JavaScript item, so exceptions are decided one at a time.
- Directory edits. The practice reports mismatches on directory profiles. Fixing a listing the business controls is its own or the agency's work unless it is ordered as a change order.
Rankings, mentions and leads are not in the specification either. The practice measures them and reports the share of answers with an interval, and guarantees none of them. A hardening keeps the site's platform and theme and does not move its hosting.