· Blog
We audit how websites present to AI systems. On September 16, 2026, we ran the same checks against our own site, generativemetrics.com, and found six gaps. Each one was small, specific, and invisible from a browser. We fixed them in two commits (d1051bc and 6b7669) and re-ran the checks.
There are two reasons to write this down. First, the failures are a sample of what any site can get wrong between a browser and a machine. Second, every item is verifiable: each fix is a named file and a specific change. Nothing below is a measurement of AI behavior — it is a record of what our pages expose and what we changed.
The homepage title had lost its brand suffix
Next.js applies a layout title template to child segments, not to the segment where the template is defined. The homepage shares the root segment, so when the root default title changed, the homepage title dropped its brand suffix with no error anywhere. We restored the suffix as a hardcoded string in app/page.tsx (commit 6b7669, one file). The root page is the one place a title template does not reach, and it needs the brand written out.
The sitemap shipped stale dates
Every URL in our sitemap carried a hardcoded last-modified date; most shared one stale value, and none were tied to the source file that changed. Anything reading it was told the site had barely changed, while releases kept shipping. The dates are now derived per route from the git history of each route source file (app/sitemap.ts), with the source file noted next to each entry so the date can be re-derived. A stale lastmod is a machine-readable statement that happens to be false; git history is a better source for it.
Our Organization data was a stub
Structured data is how a site describes itself to machines. Ours held two fields: name and url. We enriched it with logo, description, contactPoint, and alternateName (app/layout.tsx).
We deliberately did not add sameAs links. sameAs is where a site lists its official profiles elsewhere, and we do not have any real public profiles yet. Filling that field with URLs that do not exist would be a fabricated identity signal, and fabrication is not a thing we are willing to ship. Leaving it empty until there are real profiles to point to is the honest state.
robots.txt blocked our own probe endpoint
Our robots.txt disallows /api by default, which is right for private endpoints. But the rule was blanket, and it also covered /api/public-probe — the unauthenticated quick-check endpoint that exists for agents. An agent that followed our published policy was told to stay away from the one endpoint meant for it. We added a targeted Allow: /api/public-probe while keeping the rest of /api disallowed (app/robots.ts).
The probe was live but undiscoverable
Allowing a path in robots.txt only helps if an agent knows the path exists. /api/public-probe had shipped without documentation. We documented it in llms.txt and on the API docs page, including the JSON body shape and the per-IP limits. Access and discoverability are separate checks, and we had failed the second one.
Plain definitions on the pages a machine reads first
The homepage, pricing, and FAQ now each carry a roughly 60-word definition block: what the service is, what it records, what the results are, and where the limits are. The purpose is extraction — a machine should be able to pull a first-pass explanation from the page itself instead of assembling one from marketing copy. The blocks say the same thing the rest of the site says, limits included.
What this exercise does and does not prove
The checks above are the ones the product automates: what each named AI crawler is permitted to do against your declared policy, what machine-readable files declare, what structured data says, and what a fetcher receives in raw HTML without running a browser. Running them on our own site produced a short, concrete list, which is the point — a finding you can name is a finding you can fix.
It does not prove that any AI system will cite, rank, or recommend this site. It does not prove the product works for your site; one site, reviewed once, is not evidence about any other site. It does not prove the fixes are permanent — any of them can be undone by a later change, which is why the sitemap dates come from git and why the checks can be re-run. And it does not measure what any model will do with the content it can reach.
What it does prove is narrower and verifiable: the gaps were found, the changes shipped, and the files are in the repository history. If you review how your own site presents to AI systems, that is the standard to hold the review to — named findings, named fixes, and no claims beyond what was observed.
Run the same checks on your own site.