What making our own site AI-ready taught us

We spend our days measuring whether AI shopping assistants can find, understand, trust, and recommend product catalogs. So when we rebuilt catalogsignal.com on a mainstream hosted website builder, we decided to hold our own site to the same principles we use to evaluate product catalogs. It was a useful exercise in humility. A site can look finished to a human and still read as half-built to a machine, and ours was no exception. Here is what we hit, and what we changed.

Structured data that only exists after JavaScript runs is structured data an agent may never see. Plenty of platforms inject schema, forms, and even content on the client side, after the page loads. A person with a browser sees everything. A crawler or retrieval pipeline that reads the raw HTML sees a shell. We moved our important markup, the Organization, Service, FAQ, and Article schema, into the server-returned HTML so it is present on first read, with no JavaScript required. If an AI system has to execute your page to understand it, assume some of them will not.

Check your sitemap against the pages you want discovered. Squarespace automatically updates its sitemap when content changes, usually within an hour and sometimes within 24 hours. Pages hidden from search, disabled, or password-protected are excluded. Compare the published URLs with your intended content, check page settings, and allow for the update window. A page's position in the navigation alone does not determine whether it belongs in the sitemap. Squarespace's sitemap guide explains the included content.

A contact form a browser can use is not the same as a contact path an agent can use. Our contact form supports direct inquiries from visitors. It is also injected by script, so a reader that does not run JavaScript sees no fields at all. We could not change how the platform renders the form, so we made sure a plain, crawlable contact path, a visible email address in server-rendered text, sits right beside it. The principle generalizes: every action you want a machine to be able to take should have a text-readable version.

Make each machine-readable promise easy to verify. Our site includes a structured AI-agent brief describing the company, products, and contact paths. For any brief, feed, or endpoint, check the actual response, format, and access behavior before linking to it. That gives readers and agents a dependable route to the information you intended to share.

Repeated chrome and duplicate URLs are quiet noise that dilutes your real content. When every page carries its own copy of the header and footer, and when a staging address serves the same pages as your primary domain, crawlers and extraction pipelines spend effort on boilerplate and can get confused about which URL is canonical. We leaned on canonical tags pointing at the primary domain, and kept the unique substance of each page as early and as clean as the platform allowed.

None of this is an argument against hosted builders. They get a credible site live quickly, and many commerce teams run on these platforms. The point is narrower and more useful: the things that make a site easy for a person are not the things that make it legible to an agent, and the gap is invisible until you measure it. Server-rendered meaning, an honest and complete sitemap, text-readable actions, and clean canonical signals are not exotic. They are just easy to skip when the human preview looks fine.

And resist the urge to rip-and-replace. Every limit we hit had a tempting heavy-handed fix: a different host, a custom server, a stack we would own end to end. We did not reach for any of them. Server-rendered schema, a visible email beside the form, an honest AI brief, and canonical tags were all things we could do within the platform we already had. We even checked the one setting that most directly controls AI access, the crawler controls, and confirmed our site allows search and AI crawlers rather than assuming it. Before you migrate off a platform that is otherwise serving you well, it is worth asking whether the gap is in the platform or just in how you have configured and filled it. Most of the time it is the latter, and that is the same pragmatic, work-within-the-constraints approach CatalogSignal brings to catalog improvement: meet the system where it is.

That is the same gap we find in product catalogs every day. A page that reads beautifully to a shopper can still be missing the one attribute, the one parseable claim, the one machine-readable signal that decides whether an assistant puts it on the shortlist. Building our own site to the standard we measure for others was a good reminder that AI-readiness is something you check on purpose, not something you inherit from a platform.

Curious where your catalog stands? A Commerce Eligibility Index™ assessment shows where your products are ready for AI discovery and gives you the prioritized plan to make the whole catalog stronger. Get a preliminary catalog check.

About this note

These are practitioner notes from rebuilding catalogsignal.com. The principles described here also inform the Commerce Eligibility Index: readable content, consistent facts, verifiable evidence, and clear discovery paths. A service website and a product catalog need different tests.