53
Fields on a finding
Flagship
AuditBuilder
A working tool built on top of a fifty-three-field SEO finding record. Brands, then audits, then findings, with every finding stored as data rather than as a paragraph, and one export that produces both the document and the register.
What It Is
AuditBuilder is findings management for SEO audits. You create a brand, run audits under that brand, and record findings under an audit. The finding is the unit the entire tool is built around.
9
Groups they fall into
5
Questions they answer
The nine groups are identity, scope, evidence, impact, remedy, the risk of the fix itself, the judgements priority is computed from, lifecycle, and what happens after delivery.
Those fields are not a form for its own sake. They answer five questions in order, and a finding that cannot answer all five is not finished:
- What is wrong?
- How you know.
- What it costs.
- What to do about it.
- How you will know it worked.
The last one is written before the fix rather than after, which is the difference between an audit and a list of opinions.
That structure is what makes an audit something other than a document. A register of records can be:
- Sorted by score and filtered by effort.
- Handed to a development team as a work queue.
- Printed as an argument for the client.
- Driven by an agent over an API.
- Set beside the same brand's audit from six months ago.
It is the record structure my SEO Audit deliverable specifies, running as software instead of as a template I copy.
The Problem It Solves
SEO audits are almost always written as prose. The finding is the atomic unit of an audit, but nothing stores it as a unit, so the audit cannot be:
- Diffed against the last one.
- Re-run.
- Filtered by severity.
- Handed to a dev team as a queue.
It can only be read in the order somebody typed it. A document is also frozen: the day it is delivered is the last day it is accurate, because there is nowhere to record that finding eleven shipped, finding four was declined and why, and finding nine was verified in production three weeks later.
Storing the finding as a record fixes all of that at once, and none of it can be fixed while the finding is a bullet point.
Where It Gets Used
It gets used in five situations, and the last one is why signup is open.
- Building a roadmap. Running a client audit and needing findings ordered by a score you can defend, so the sequence survives being questioned in the meeting where it is presented.
- One export, two artifacts. The PDF document is the argument, for the meeting. The Google Sheets register is the record, for the six weeks afterwards when somebody who was not in the meeting needs to know what was agreed.
- Re-auditing. Coming back to a brand six months later and comparing against what the last audit found rather than starting from a blank document.
- Driving it from an agent. Pointing Claude or anything else that speaks MCP at a workspace, so findings written by a model obey the same field rules as findings written by hand.
- Other people's client work. Another independent consultant running their own audits in it, which is the reason it has public signup at all.
How It Works
Three levels of record, and then the two artifacts that come off them. The loop below plays one finding from record to register to export, then starts again.
-
Brands
The top-level container: the client's domain, their colours and logo, and a registry of the vocabulary their findings are allowed to use. Putting pillars, templates, owner teams and metrics on the brand instead of typing them per finding is what makes the register sortable and the roadmap groupable. Everything belongs to a brand, which is what makes a re-audit a comparison rather than a fresh start.
-
Audits
An audit is a dated pass over a brand, carrying what you looked at, what you looked with, and what you could not see. Its findings belong to it, so two audits of the same brand sit side by side instead of overwriting each other. It also carries what the cover calls it, because not every audit is a technical one.
-
Findings
Fifty-three fields per finding, and a priority score computed from six of them rather than asserted. Evidence capture is manual image upload in this version, but the locator fields are stored regardless, so automated capture can be added later without anyone re-entering a record.
-
Output
Export
One button, two artifacts. A branded PDF document with a whole page per finding, and a Google Sheets register carrying every field with a note under each column header explaining what it means. Both links stay on the audit permanently once exported, and the PDF link is signed for thirty days rather than left public. JSON, CSV and Markdown come off the API instead.
Stated up front rather than discovered: there is no billing and no support. The tool is free, it is maintained because I use it on my own client work, and nobody should adopt it expecting a support desk. That is a feature of the arrangement, not an apology for it.
What Comes Out Of It
Both of these are real. They are the sample audit that every new workspace is seeded with, run through the same exporter a client audit goes through, not a mockup drawn to look like one.
The document
Northbeam Outfitters, Technical SEO Audit. Fifteen pages. Turn them with the arrows, or with the arrow keys once the document has focus.
A whole page per finding, every one carrying the claim, the evidence behind it, what it costs, the fix broken into steps, and the check that will prove it worked. The band and the score sit in the margin of each one, so the ordering is arguable from the page rather than only from the spreadsheet.
The register
The same audit, every field of it. Thirty-three columns, ten findings. Scroll it sideways.
| Ref | Finding | Priority | Score | Status | Owner | Effort, days | Wave | URLs affected | Templates | What it costs | The fix | How it will be verified | Verify by | Pillar | Markets | Kind of harm | Metric at risk | Exposure | When it bites | Confidence | Data window | Sources | Steps | Blocked by | External blockers | Severity | Reach | Leverage | Fix risk | Decision | Verified on | What changed |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Permanent ID for this finding. | What is wrong, stated as a claim you can agree or disagree with. | Position in this audit: P1 do first, P2 scheduled, P3 alongside, P4 monitor. | 0 to 100, computed. | Where the fix stands right now. | The team that can make this change. A team, not a person. | Engineering days, estimated. | Roadmap phase. | URLs with the problem. | Which page templates are hit. A template problem is one fix. | The exposure, and where that number came from. | What to do, written as an instruction to the owner. | The check that proves it fixed. Written before the fix, not after. | When to run that check. | Which area of the audit this came from. | Which locales or country sites are affected. | Crawl waste, duplicate content, lost visibility, broken experience or compliance. | Which measure moves if this is not fixed. | The size of the problem, with its unit. | Already happening, next crawl cycle, next release, or latent. | How strongly the evidence supports the claim, and why if not high. | The span the evidence covers. Without it nobody can re-verify. | The tools and datasets the finding was built from. | The fix broken down so an engineer needs no follow-up question. | Findings that have to land before this one can start. | Things holding it up that are not findings: a window, a sign off. | 1 to 5, how bad on its own. | Share of pages hit. | 1 to 5, what it unblocks. | Risk of the fix itself. | The client call on the recommendation: accepted, deferred or rejected. | When it was confirmed. | What happened, in plain words, for whoever reads this later. |
| CRWL-001 | Faceted navigation exposes 41,286 crawlable parameter URLs that duplicate 214 category pages | P1 | 90 | Open | Platform engineering, with SEO reviewing the link component change | 0.5 | 1 | 41286 | Category listing, Collection filter | Measured from 30 days of Cloudflare Logpush records filtered to verified Googlebot by reverse DNS. 1,412,880 Googlebot requests total, 542,545 of which resolved to URLs carrying a filter parameter. | Stop the filtered URL space from being crawled at all, rather than trying to consolidate it after the fact. Canonicals are already correct and Google is ignoring them because the volume is too high for the crawler to reconcile. | Re-run the Screaming Frog crawl with the same configuration and confirm fewer than 500 filtered URLs return 200. Pull 30 days of logs and confirm filtered URLs are under 5 percent of verified Googlebot requests. Check the Search Console Pages report for a fall in Discovered, currently not indexed. | 2026-10-15 | Crawl efficiency | US, CA, UK | Crawl waste | Crawl requests spent on indexable revenue pages | 38.4 percent of crawl budget | Already happening | High. Three independent sources agree. The crawler enumerated the URL space directly, the server logs confirm Googlebot is fetching them at scale, and Search Console reports 36,900 URLs in Discovered, currently not indexed. Nothing here rests on estimation. | 2026-07-14 to 2026-08-13 | Screaming Frog SEO Spider 21.4, Cloudflare Logpush server logs, Google Search Console Pages report | 1. Add a robots.txt disallow for /collections/*?*filter= and the four other parameter prefixes listed in the appendix 2. Strip filter parameters from every internal link in the facet component so no crawlable path into the space remains 3. Return the parameter URLs as noindex,follow for 60 days before the disallow lands, so already indexed variants can drop out 4. Set the Shopify theme to render facet state client side after the first interaction rather than as a link href 5. Re-pull the log sample 30 days after deploy and confirm the filtered share of crawl is below 5 percent | Theme deploy window, currently fortnightly | 5 | 0.85 | 5 | 1.05 | ||||
| IDX-001 | Paginated category pages canonicalise to page one, removing 8,940 products from the index | P1 | 64 | In progress | Platform engineering | 0.5 | 1 | 1206 | Category listing | Count of distinct product URLs whose only internal link path runs through a paginated category page at ?page=2 or deeper, taken from the Screaming Frog inlink report. Verified by removing category paths from the link graph and re-running the orphan report. | Make each paginated page self canonical so the products it links to stay in the crawl graph, and give the deep tail a second discovery path that does not depend on pagination at all. | Crawl the category templates and confirm every paginated URL is self canonical. Re-run the orphan report and confirm zero products are reachable only through pagination. Track impressions for the affected product set in Search Console over the following six weeks. | 2026-10-01 | Indexation | US, CA, UK | Lost visibility | Organic entrances to long tail product pages | 8940 products effectively deindexed | Already happening | High. The canonical behaviour was read directly from rendered HTML on all 1,206 pages. The index coverage figure comes from the URL Inspection API run against a random sample of 400 of the 8,940 orphaned products, extrapolated with a stated margin, so the product count is measured and the index count is a sample estimate. | 2026-08-11 to 2026-08-13 | Screaming Frog SEO Spider 21.4, Google Search Console URL Inspection API | 1. Change the canonical on ?page=2 and deeper to reference the paginated URL itself 2. Keep the noindex off those pages, they should be indexable and thin, not absent 3. Publish an HTML sitemap of every product grouped by category, linked from the footer 4. Confirm the XML sitemap lists all 4,213 products, it currently lists 3,006 5. Request validation in the Search Console Pages report once deployed | 5 | 0.7 | 4 | 1.2 | |||||
| SD-001 | Product structured data fails validation on 4,013 pages because offers.priceValidUntil is absent and aggregateRating has no reviewCount | P2 | 55 | Open | Front end engineering | 1 | 1 | 4013 | Product detail | Direct count from parsing the JSON-LD block on all 4,213 crawled product pages and testing each against the Product schema requirements Google publishes for merchant listings. | Fix the two missing properties in the Shopify product schema template. Both values are already available in Liquid, neither needs new data. | Re-crawl all product pages with the same custom extraction and confirm zero blocks are missing either property. Confirm the Search Console Merchant listings report moves the affected items to Valid. Spot check five pages in the Rich Results Test per market. | 2026-09-30 | Structured data | US, CA, UK, DE, FR, AU | Lost visibility | Rich result eligibility for product listings | 4013 product pages ineligible for rich results | Already happening | High. Every product page was crawled and its JSON-LD extracted and parsed, so this is a census rather than a sample. Search Console independently reports 4,011 items with issues against my 4,013, a two page difference explained by pages published after the crawl. | 2026-08-11 to 2026-08-15 | Screaming Frog SEO Spider 21.4 custom extraction, Google Rich Results Test, Google Search Console Merchant listings report | 1. Add offers.priceValidUntil rendering as the current date plus 365 days 2. Add aggregateRating.reviewCount from the review app metafield, and suppress the whole aggregateRating node when reviewCount is zero rather than emitting an empty rating 3. Validate 20 sample pages across all six markets in the Rich Results Test before deploy 4. Request validation in the Search Console Merchant listings report after deploy | Review app metafield mapping needs confirming with the merchandising team | 4 | 0.95 | 4 | 1.2 | ||||
| CRWL-002 | Internal search result pages are indexable and account for 12,407 crawled URLs | P2 | 32 | Fixed | Platform engineering | 0.25 | 1 | 12407 | Internal search results | Count of verified Googlebot requests with a path beginning /search in 30 days of Cloudflare Logpush records, reverse DNS verified. | Block internal search from robots.txt and remove the internal links that feed it. | Fetch robots.txt and confirm the disallow is live. Re-run the crawl and confirm /search URLs are no longer reachable from an internal link. Confirm Googlebot requests to /search fall below 1,000 per 30 days in the logs. | 2026-09-20 | Crawl efficiency | US, UK | Crawl waste | Crawl requests spent on indexable revenue pages | 81340 Googlebot requests over 30 days | Next crawl cycle | High. The crawl enumerated the URLs and the logs confirm Googlebot is fetching them. The index count is a site: operator sample rather than a Search Console figure, so it is directionally right rather than exact, and I have said so rather than quoting it as measured. | 2026-07-14 to 2026-08-13 | Screaming Frog SEO Spider 21.4, Cloudflare Logpush server logs | 1. Add Disallow: /search to robots.txt 2. Add noindex to the search template for 30 days before the disallow, so indexed results drop out first 3. Remove the popular searches module from the footer, which is the only internal link source into the space | 3 | 0.55 | 3 | 1.2 | 2026-08-29 | Deployed with the 27 August theme release. Logs for the following week show Googlebot requests to /search down from roughly 2,700 per day to 46. Leaving open for a further 30 days to confirm the indexed results drop out before marking verified. | |||
| INTL-001 | The hreflang cluster omits return tags for en-CA on 1,402 pages, so the annotation is ignored | P3 | 17 | Open | Front end engineering, with the localisation lead confirming the market map | 0.5 | 2 | 1402 | Product detail, Category listing, Editorial | Count taken from the Screaming Frog hreflang report, which resolves each declared alternate and checks for a reciprocal declaration. Manually verified on twelve sampled pages by fetching both sides of the pair. | Make the hreflang block render from a single shared market map rather than per template, so reciprocity cannot drift again. | Re-run the Screaming Frog hreflang report and confirm zero unreciprocated annotations across all six markets. Fetch three pairs per market by hand and confirm both sides declare each other. | 2026-11-01 | Internationalisation | CA, US | Lost visibility | Correct market targeting for Canadian searchers | 1402 pages with a broken annotation | Next crawl cycle | Medium. The missing return tags are measured directly from the crawl and are not in doubt. What is uncertain is the consequence. Google states unreciprocated annotations may be ignored, but the CA storefront sits below the CrUX reporting threshold and Search Console does not break performance out by hreflang cluster, so I cannot show the traffic effect, only the defect. | 2026-08-11 to 2026-08-16 | Screaming Frog SEO Spider 21.4 hreflang report, Manual review | 1. Move the hreflang block out of the three templates and into one shared snippet driven by the market map 2. Include x-default pointing at the US storefront 3. Re-crawl and confirm every declared alternate reciprocates 4. Add an hreflang reciprocity check to the monthly crawl so a regression is caught rather than found in the next audit | Market map needs sign off from the localisation lead | 3 | 0.35 | 4 | 1.1 | ||||
| PERF-001 | Mobile category pages report a 75th percentile LCP of 4.8 seconds, driven by an unsized hero image | P3 | 12 | Open | Front end engineering | 2 | 2 | 214 | Category listing | CrUX 28 day rolling field data for the origin, filtered to the /collections/ URL group and mobile form factor, pulled 12 August. Only 31 percent of visits meet the good threshold of 2.5 seconds. | Give the hero image explicit dimensions, stop lazy loading it, and serve a viewport appropriate source. The element is above the fold on every category page and is the LCP candidate in every trace. | Re-run PageSpeed Insights on ten category URLs and confirm the lab LCP is under 2.5 seconds. Wait a full 28 day CrUX window after deploy and confirm the field 75th percentile is under 2.5 seconds and the good share is above 75 percent. | 2026-11-15 | Page experience | US, UK | Broken experience | Mobile conversion rate and page experience signals | 4.8 seconds at the 75th percentile | Already happening | Medium. The field data is real user data and reliable for the US and UK groups. The cause is a lab observation from six traced page loads on a throttled connection, so the diagnosis is well supported but not proven at scale. Canada is excluded from the claim entirely because CrUX has no data for that storefront. | 2026-07-16 to 2026-08-17 | PageSpeed Insights field data CrUX, Chrome DevTools performance trace, Screaming Frog SEO Spider 21.4 | 1. Remove loading=lazy from the hero image, it is always above the fold 2. Add width and height attributes so the layout does not shift while it loads 3. Add a srcset with 640, 960 and 1440 wide sources and a sizes attribute matching the template 4. Add fetchpriority=high to the hero img 5. Re-measure in the lab, then wait 28 days for the field data to move | Design needs to supply the 640 and 960 wide crops | 4 | 0.6 | 3 | 1 | ||||
| CMP-001 | The consent banner blocks main content rendering for EU visitors until a choice is made | P3 | 3 | Accepted risk | Front end engineering, with legal reviewing the consent logic separately | 1.5 | 3 | 42 | All templates, DE and FR storefronts | Observed by loading twelve pages across the DE and FR storefronts in a clean Chrome 141 profile with no stored consent, and measuring rendered main element content before and after interacting with the banner. | Render the page content behind the banner rather than in place of it. The banner can overlay, it does not need to gate. | Load ten pages per EU storefront in a clean profile and confirm main content is present in the DOM and visible behind the overlay before any consent choice. Re-run the URL Inspection live test on three pages per market. | 2026-12-01 | Compliance | DE, FR | Compliance exposure | Accessibility and user experience for EU visitors | 0 main content bytes rendered before consent | Latent | Low. This is a single day manual observation on a small sample of pages, not a crawl. Googlebot appears to render the content fine, which is why I have scored the search impact low. The reason it stays in the register at all is the user experience and the accessibility exposure, and both of those are outside my measurement, so I have flagged it rather than quantified it. | 2026-08-19 to 2026-08-19 | Manual review Chrome 141, Google Search Console URL Inspection live test | 1. Change the banner from a blocking interstitial to a bottom anchored overlay 2. Keep non essential scripts gated behind consent, only the content rendering should change 3. Have the accessibility reviewer confirm focus order and keyboard dismissal 4. Refer the consent logic itself to counsel, it is outside the scope of this audit | Legal sign off on any change to the consent flow | 5 | 0.2 | 2 | 0.9 | Client has accepted this for now. Legal review of the consent flow is scheduled for Q4 and they do not want the banner touched before that lands. Re-raise in the Q1 audit if it is still open. | |||
| CNT-001 | The same 180 word introduction appears on 187 category pages | P4 | 2 | Open | Content team | 5 | 3 | 187 | Category listing | Screaming Frog near duplicate analysis at a 95 percent similarity threshold, confirmed by diffing the extracted intro block across all 214 category pages. | Replace the shared block with a short intro written per category. This is a content task, not an engineering one, and it can run in the background across a quarter. | Re-run the near duplicate report and confirm no two category pages exceed 80 percent similarity on the intro block. Spot check the top 30 categories by hand. | 2027-01-15 | Content | US, CA, UK | Duplicate content | Perceived page quality and topical relevance | 187 category pages with no distinct copy | Latent | Medium. The duplication is measured and certain. Whether it matters is a judgement. These pages still rank and the duplication is internal rather than cross domain, so I have weighted this as a quality problem to fix opportunistically rather than a ranking emergency, and I would not claim a traffic figure for it. | 2026-08-11 to 2026-08-18 | Screaming Frog SEO Spider 21.4 near duplicate report, Manual review | 1. Write a 60 to 90 word intro per category, prioritising the 30 categories that carry the most organic entrances 2. Remove the shared block entirely rather than leaving it below the new copy 3. Leave the remaining categories without an intro rather than filling them with the shared block | Category priority list from the analytics team | 3 | 0.4 | 2 | 1.1 | ||||
| LINK-001 | 341 product pages have no internal link from anywhere on the site | P4 | 2 | Reopened | Merchandising, with platform engineering for the sitemap rule | 3 | 3 | 341 | Product detail | Screaming Frog orphan URL report, cross referenced against the XML sitemap and the Shopify product export to separate live from discontinued lines. | Decide per product whether it is live or retired, then either link it or remove it from the sitemap. Leaving them orphaned but submitted is the worst of both. | Re-run the orphan report and confirm zero live products are orphaned. Fetch the XML sitemap and confirm no discontinued product URLs remain. Check that the 138 relinked products pick up impressions within eight weeks. | 2026-12-15 | Internal linking | US, CA, UK, DE, FR, AU | Lost visibility | Discoverability of in stock long tail products | 138 live products with no link path | Next release | Medium. The orphan count is measured against a complete crawl and is reliable. The judgement is what to do about it, because 203 of the 341 are discontinued lines that arguably should not be in the sitemap at all. So the finding is really two, and I have kept them together because the fix is one decision. | 2026-08-11 to 2026-08-18 | Screaming Frog SEO Spider 21.4 orphan report, Google Search Console Performance report, Manual review | 1. Remove the 203 discontinued products from the XML sitemap and redirect them to their closest live equivalent 2. Add the 138 live products to their correct category so the normal link path picks them up 3. Add a sitemap freshness check so retired products drop out automatically rather than being cleaned by hand | Merchandising needs to confirm which lines are genuinely retired | 2 | 0.3 | 3 | 1.05 | Marked fixed on 22 August after merchandising relinked 138 products. Re-crawled on 28 August and found 47 new orphans created by the September range change, so the underlying process problem is unfixed even though the backlog was cleared. Reopened. | |||
| UX-001 | Breadcrumb markup is present in the DOM but visually hidden on mobile below 768px | P4 | 0 | Verified | Front end engineering | 5 | 4 | 4213 | Product detail | GA4 sessions on product detail pages for the 90 days to 12 August, segmented by device category. Mobile accounts for 71 percent. | Show the breadcrumb on mobile. The markup is already correct and Google is already using it, this is purely a display rule. | Load product pages at 360, 390 and 414px wide and confirm a visible breadcrumb trail. Re-run the Rich Results Test to confirm the BreadcrumbList is still valid after the markup moves. | 2026-09-15 | Page experience | US, CA, UK, DE, FR, AU | Broken experience | Mobile navigation depth and category discovery | 71 percent of product sessions with no visible breadcrumb | Latent | High. All three parts are measured directly. The markup was extracted from every page, the visual absence was confirmed across four device widths, and the mobile share comes from GA4. The reason this scores low is not uncertainty, it is that the structured data is valid and eligible either way, so the cost is navigational rather than search visibility. | 2026-08-11 to 2026-08-19 | Screaming Frog SEO Spider 21.4, Manual review Chrome 141 device emulation, Google Analytics 4 | 1. Remove the display none rule on .breadcrumb below the 768px breakpoint 2. Truncate the middle levels with an ellipsis rather than hiding the whole trail 3. Confirm the change does not push the product title below the fold on a 360px viewport | Design needs to specify the truncated mobile treatment | 2 | 0.15 | 2 | 0.95 | 2026-08-30 | Shipped with the 28 August release. Verified at all three widths on 30 August, breadcrumb visible and truncated as specified. BreadcrumbList still validates. |
The italic line under each header is the part worth noticing. A register goes to people who were not in the audit, and a bare column called Reach tells them nothing. You choose which columns travel and in what order before you export.
The document is for the meeting. The register is for the six weeks afterwards, when somebody who was not in the meeting needs to know what was agreed and what is still open. They are not two formats of the same thing, which is why the export produces both rather than asking you to pick.
Worth stating plainly: this is the seeded sample, so it is what you get to look at before you have typed anything. Sign in, open it, press Export, and you have your own copy of both files inside a minute.
The Opinions It Enforces
Most of what is unfamiliar in the tool is unfamiliar because it is a deliberate constraint, and a constraint nobody explains just reads as an obstacle. These are the five worth knowing before you decide whether it suits how you work.
- Priority is computed, not argued. You supply six judgements: severity, reach, confidence, leverage, effort in engineering days, and a triple for how dangerous the fix itself is. The score falls out of them, on a nought to one hundred scale. Effort sits under a square root on purpose: divide by it outright and the register recommends nothing but trivia, ignore it and the register recommends nothing you can ship this quarter. The same inputs always give the same order, so two audits written months apart stay comparable, and when a client argues with the sequence the argument is about an input you can both look at.
- A band is a position inside its own audit. P1 is the top fifteen percent of that audit's client-facing findings, P2 the next twenty-five, P3 the next thirty, P4 the rest. Cutting at fixed scores meant only a finding that was severe and high leverage and near total in reach ever reached P1, so an audit where nothing was catastrophic read as though nothing mattered. The band answers what to do first here. The score, which is printed on every page, is what compares one audit to another. Findings that score the same always share a band.
- Verification is written before the fix. The field that says how you will know it worked is filled in when the finding is raised, not after somebody has shipped something and needs a check that flatters it.
- Every finding is either client or internal. An internal finding stays in the app: not in the document, not in the register, not in anything handed over. It is for the things worth recording that are not worth saying, which on most engagements is a real category rather than a rare one.
- Two ways to write an audit, chosen once. Manual leaves every field to you and enforces nothing, which is right when the work is qualitative and forcing numbers onto it would be dishonest. Logic makes the database do the work it can do without you: references generated, windows and reach derived, status transitions constrained, and a write that contradicts a derived value rejected with a reason. The mode is set per audit and cannot be changed afterwards, because half a record written under one set of rules and half under another is worse than either.
The claim this rests on: an SEO finding is a claim somebody can disagree with, not a label. "Product pages canonicalise to their category" is a claim. "Canonical issues" is a heading. Every constraint above exists to stop the second thing from being deliverable.
REST And MCP
Everything the interface does is available programmatically, and the two surfaces run on the same handlers rather than on two implementations that drift apart. An agent writing findings obeys exactly the same field rules as a person writing them, which is the only version of this worth having.
Programmatic access
- Keys
- Minted per workspace in the app, shown once, revocable. A key carries the workspace's permissions and nothing wider.
- MCP
- One endpoint to paste into Claude or anything else that speaks the protocol. Fifteen tools, covering brands, audits, findings, exhibits, the roadmap and export.
- REST
- Twenty-two routes over the same records, with JSON, CSV and Markdown as export formats.
- Field schema
- A single call returns every field, its type, its allowed values and whether it is required. An agent asks first and then writes, rather than guessing and being rejected.
- Self-describing
- The API documents itself at its root, and the documentation page inside the app reads from that, so adding a route updates the docs without anyone remembering to.
Who It Is For
Independent SEO consultants and in-house leads who run the same audit repeatedly and want the findings to outlive the delivery date. If you have ever re-typed last quarter's findings into this quarter's document, it was built for you.
Signup is open.
- Sign in with Google, GitHub or Microsoft, or with a one-time email link.
- A new workspace arrives with a sample audit already in it, clearly labelled as a sample and safe to delete, so there is something real to open and export before you have typed anything.
- A workspace holds more than one person: invite them as owner, editor or viewer.
There is also a walkthrough inside the app that explains the record, the scoring and the export in about ten minutes, which is the honest amount of reading this thing needs before it makes sense.
- Not for anyone who needs a managed SaaS. No support desk, no SLA, no account manager, no invoice.
- Not an audit generator. It stores, structures and sequences findings. Finding them is still your job.
- Not a project tracker. It records what was found, what was decided and whether it was verified. It is not where your engineers work.
Status And Access
This is the one product here you can sign up for and use today.
Status and access
- Status
- Live since September 2026
- Address
- auditbuilder.jakelabate.com
- Sign-in
- Public signup. Google, GitHub or Microsoft OAuth, or a one-time email link.
- On day one
- A workspace with a sample audit already seeded in it, labelled as a sample and safe to delete.
- Workspaces
- One per account, shareable. Invitations carry owner, editor or viewer.
- Programmatic
- A REST API and an MCP endpoint, keyed per workspace.
- Cost
- Free. There is no billing in the product.
- Support
- None offered. It is maintained because I run my own audits in it.
- Your data
- Terms and a privacy policy are in the app, and an account can be deleted from inside it, with what will be destroyed listed before you confirm.
- Repository
- JakeLabate/audit-builderPublic on GitHub
- License
- MIT.
- Exports
- A branded PDF and a thirty-three column Google Sheet from the app. JSON, CSV and Markdown from the API.
- Can you use it today
- Yes. Sign in, open the sample audit, and press Export.