The SEO checklist for a site an agent built

An agent-built site fails search in a particular way. It is rarely the copy and almost never the design. It is the things with no visual representation, which means they survive every review a human does by looking at the screen. These are the ones we keep finding, including several that are specific to the stack most agents reach for and are not in any of the generic AI website checklists.

Metadata that silently inherits

In an app-router project, metadata merges down the route tree. A child route that sets a title and description but not an openGraph object inherits the parent's entire openGraph, which includes its url. The result is every page on the site declaring the same canonical social URL and sharing the same preview image. Nothing errors, the pages look right, and every share of every article shows the homepage card. The generateMetadata reference documents the merge behaviour; the failure mode and the fix are in why child routes ship the parent's og:url.

Nobody asks for a sitemap, so nobody gets one. Worse than a missing sitemap is a generated one that lists pages the site also marks noindex, or omits pages that should be in it, because the two are usually computed from different logic and drift apart the first time a publishing rule changes. Google's guidance on building a sitemap is short and worth following literally.

The check that catches it is to compare the two lists programmatically rather than spot-check them. Every URL in the sitemap should return 200 and carry no noindex; every indexable page should be in the sitemap. We run that as a build step, and it has caught a publishing-date bug twice that no amount of looking at pages would have found.

Dates, and the trap of building once

If posts are gated on a publication date, that comparison runs at build time on a statically generated site. A post dated tomorrow will not appear tomorrow. It will appear the next time somebody deploys, which might be a month later. Either set a revalidation window so the pages recheck themselves, or accept that publishing requires a deploy and schedule one. Getting this wrong is invisible until somebody asks why the post they scheduled never went live.

A second date trap: the comparison usually runs in UTC while the person setting the date is thinking in their own timezone. A post dated today, set in the evening west of Greenwich, is tomorrow in UTC and ships as unpublished.

Images: the two failures that produce no error

• A quality value not present in the framework's allowlist makes the optimiser return a 400. The image breaks at runtime and the build is clean, so it ships. The Image component reference lists what has to be configured.
• The optimiser caches by source path, not by file contents. Replace an image in place, keep the filename, and the old one keeps being served through a full rebuild. It fails partially, so some images update and some do not, which reads as a CSS bug.
• Hero images are the usual cause of a slow agent-built site, and the largest element in the viewport is what Largest Contentful Paint measures.

Structured data that validates and lies

An agent will produce JSON-LD readily and it will usually validate, because validation checks shape rather than truth. What it does not check is whether the Organization has the right address, whether the Article author is a real person with a page, whether the FAQPage questions appear on the page as visible text, or whether a Service describes something the business sells. Google's structured data introduction is explicit that markup must describe visible page content, and the common agent failure is markup that describes an idea of the page.

Thin pages, generated at speed

The thing an agent is best at is producing forty variations of a page, and that is exactly the thing search punishes. If you generate location or service pages, measure them against each other rather than trusting that they feel different: strip every proper noun, then compare each pair. Anything above about 0.95 similarity is the same page with a name swapped, and we have measured corpora where the median was 0.88 and nobody had noticed.

Crawlers, including the ones that do not render

Server-rendered output is not optional if you care about AI search surfaces, because the assistant crawlers largely do not execute JavaScript. Check what they actually receive rather than what the page shows you, which is covered in what an AI crawler receives when it requests your page, and check that your robots rules allow the ones you want, which is in AI crawlers and robots.txt. Google's own position is that this is still SEO rather than a separate discipline, stated plainly in its AI optimization guide.

Run it as a check, not a memory

Every item above is testable, which means none of them should depend on anybody remembering. Put them in a script that runs against the built output and fails the build, or package them as a skill you invoke before every launch. The difference between a team that ships these bugs and one that does not is never diligence. It is whether the check exists. If you are diagnosing a site that is already live, start with not indexed or not ranking, because the two have completely different fixes and the wrong diagnosis wastes a month.

Two of the checks above deserve their own pages. Page speed is one, because the three vitals are judged on real visits rather than on your machine and an agent makes a specific, repeatable set of mistakes on each: that is Core Web Vitals on an agent-built site. The other is the environment the checks run against, since a canonical read from a local file tells you nothing about the one production actually serves: shipping to production covers that, and the hooks piece covers turning this list into gates that run on their own.