Our Process: Audit, Repair, Configure, Monitor

An exit criterion is the stated, testable condition that closes a stage. Each of the four below names the check that runs, the result required, and the artefact delivered. A stage closes on that test rather than on a calendar date or a status call, and no stage opens before the stage before it has closed — every stage consumes the previous stage's outputs as its inputs.

Read the table as four rows in order. Stage 1, Audit, 10 business days. Stage 2, Repair, 2 to 4 weeks. Stage 3, Configure, 3 to 6 weeks. Stage 4, Monitor, ongoing, reported weekly and monthly. The arithmetic behind seven to twelve weeks is plain: 10 business days is two calendar weeks, the shortest repair and configuration windows add two and three, and the longest add four and six. Each row expands into its own section below.

Audit inputs

Four inputs open the audit, and three of them come from records you already hold.

• Website address — the live domain, required
• Access to Google Search Console and the analytics property, read-only — optional, and it adds indexing status and query data to the findings
• Name, address and telephone number, spelled exactly as you use them — required, because the entity-clarity checks compare every instance against this string
• Questions your customers ask before choosing a provider — required, because they become the fixed prompt set and never change again

Audit outputs

Three documents leave the audit.

• Findings document — all 40 checks, each with its state, the evidence behind it, and the repair that clears it
• Repair list — the failed checks ranked by the reach of each fix against the working time it costs
• Citation baseline — the domains seven assistants name today against your prompt set: Google AI Overviews, ChatGPT, Perplexity, Gemini, Claude, Grok and Meta AI

Audit exit criterion

The audit is finished when three conditions hold together. All 40 checks carry a recorded state — a pass, a fail, or a measured value. The citation baseline is captured across all seven assistants named above. The findings document is in your hands.

No meeting closes this stage; the document does. You own that document whether or not stage two follows, and in-house repair from it is a supported outcome. The check categories and what each one tests are published separately — read the forty checks in detail before booking.

Repair inputs

Four inputs open repair, and all four are access rather than content.

• Administrator account on the content management system
• Access to the hosting control panel or the deployment pipeline
• Access to the DNS records and to any edge or bot-protection service sitting in front of the site
• Approval of the repair list, with every item you decline marked as declined and dated

Template count and page count set the window rather than the fault list. One fault repeated across more templates takes longer to clear than a rarer fault on a single page.

Repair outputs

Five outputs leave repair.

• Robots directives, rewritten to name eight retrieval agents explicitly: OAI-SearchBot, PerplexityBot, Claude-SearchBot, Google-Extended, ChatGPT-User, Claude-User, Perplexity-User and meta-externalagent
• Server responses, corrected so every tested template returns a 200 to each named agent rather than a challenge page
• Content, moved into the raw HTML response so the main text survives with JavaScript disabled
• Redirect chains, collapsed to a single hop between the requested URL and the live one
• Re-test report, listing every stage-one check that changed state and every check that did not

Two agents stay your decision rather than ours. GPTBot and ClaudeBot are training crawlers, and blocking either removes nothing from ChatGPT or Claude citation, because retrieval runs through OAI-SearchBot and Claude-SearchBot instead. One directive is advisory rather than binding: Perplexity's documentation states that Perplexity-User disregards robots.txt.

Repair exit criterion

Repair is finished when the crawler-access and rendering checks from stage one re-run and return zero open fails. Every affected check is re-tested rather than sampled, and the re-test report names each one.

A check that stays failed closes in one way only — as a declined item, recorded with the reason and the person who declined it. Declined items carry forward into the stage-three scope note rather than disappearing from the record.

Configuration inputs

Four inputs open configuration, and every one of them comes from you rather than from the site.

• Business facts, verified by you in writing: legal name, trading name, street address, service area, telephone number, founding year and the services you sell
• Logins for the directory and review profiles you already own
• Sign-off on the passage rewrites, because configuration changes visible wording and the wording is yours
• Names of the local organisations, associations and publications that already reference the business — these seed the corroboration list

Configuration outputs

Five outputs leave configuration.

• Entity record, published as Organization and Service JSON-LD, with every field matching a visible instance on the same page
• Identifier set, linking that record to resolvable public records including Wikidata — zero of the nine competitor pages audited in this metro carry a Wikidata identifier
• Passage formatting, applied page by page: a self-contained opening answer of roughly 40 words under each heading, and a centerpiece of roughly 400 characters beneath each H1
• Corroboration list, submitted to the directories, associations and publications named in your inputs
• Name, address and telephone string, made byte-identical across the website and every profile you own

A parser resolves the entity record before an assistant decides which company a question is about. That record is the machine-readable description of the business, and corroboration is the agreement between it and the independent sources repeating it.

Configuration exit criterion

Configuration is finished against three conditions. Every structured-data string validates and matches a visible string on the same page, character for character. The name, address and telephone number read identically across the website and every profile listed in your inputs. Every corroboration request on the list is submitted, with a date recorded against it.

Submitted, not accepted — and the distinction is deliberate. Directory editors, association secretaries and news desks decide acceptance on their own schedule, and no stage closes on a decision made by somebody outside the engagement. Acceptances land during stage four and enter the weekly change note on the date they arrive.

Monitoring inputs

Three inputs keep monitoring running, and all three are standing rather than one-off.

• Access to the website, held open for the life of the retainer, because every weekly change is an edit
• Notification of business changes — a new location, a new service, a changed telephone number — inside the week the change happens
• Approval of any new prompt series, which opens beside the original series with its own start date rather than replacing it

Monitoring outputs

Three outputs leave every reporting period.

• Weekly report, covering Google AI Overviews, ChatGPT, Perplexity and Gemini: every prompt, the domains each answer cited, and the single change made that week named with the URL it was made on
• Monthly report, adding Claude, Grok and Meta AI, plus the Bing Webmaster Tools AI Performance export of the URLs cited in Microsoft Copilot answers
• Cumulative comparison, holding every figure against the citation baseline recorded in stage one

Seven assistants are measured in total. Four run weekly — Google AI Overviews, ChatGPT, Perplexity and Gemini — because the indexes behind them refresh inside a week. Three run monthly — Claude, Grok and Meta AI — because their retrieval layers move more slowly and a weekly run against them returns the same answer rather than new signal.

Monitoring exit criterion

Monitoring carries no finish line, so it carries a closing condition per cycle instead. A weekly cycle closes when four conditions hold: the prompt set ran unchanged against the four weekly assistants, every cited domain was logged, one change was made and named with the URL it was made on, and the report was sent. A monthly cycle adds the three monthly assistants and the Bing Webmaster Tools export.

The retainer ends on your written instruction. The minimum term is three months. On the final day you receive three artefacts: the prompt set, the full citation log from the baseline forward, and the change history — the record that makes the next provider's work possible rather than a restart.

Three causes account for a missed criterion, and each one has a fixed handling.

1. Access outside our reach.

   A hosted platform that refuses a robots.txt edit, a booking system on a separate subdomain, a review platform with no editable profile. Recorded as out of scope, with the party that controls it named.

2. Repairs you decline.

   You read the item, weigh it against your own plans, and decline it. Recorded with your reason, carried into the next stage's scope note, and excluded from the exit test rather than counted as a fail.

3. Scope larger than the audit counted.

   More templates, more locations, or a second domain discovered during repair. The window is restated in writing before the extra work starts rather than reported after it.

None of the three advances the stage by decision. The exit test runs the same way in every engagement, which is the point of publishing it.