The Cheapest AI-Readiness Fix Is a Redirect Map

Short version: A store changed its theme over the weekend — cleaner, faster, nicer. On Monday, three AI assistants were still recommending a product page that now returns a 404. The store never stopped selling that product; it just moved to a new URL, and nobody told the machines. This is the quietest way to fall out of AI recommendations, and it has nothing to do with schema or content. Beautiful structured data behind a broken URL is worth nothing — the agent bounces before it ever reads the markup. The fix is the cheapest one on the whole AI-readiness list, and you do it first.

#The quietest way to fall out of an AI answer

Most AI-readiness advice starts one layer too high. Schema, content, entity signals — all of it assumes the agent reached the page. Before any of that matters, the agent has to resolve a URL: to reach your product in the moment it's answering a shopper, and to cite you afterward when the buyer asks again.

A URL is the one thing an agent can't work around. It doesn't guess that your /products/old-handle moved to /products/new-handle. It requests the address it has, and if that address 404s, loops, or lands on a soft-404 page that returns "200 OK" with a "not found" message, the agent does the fastest thing available: it drops you from the answer, or it falls back to a cached version from before the move — often with a price or availability that's no longer true.

Search engines forgave this for years. A crawler re-discovers a moved page over weeks and still ranks the domain. An agent answering a live shopping question has no weeks. The failure is silent — nothing 404s in your analytics the way a human would notice — and it's immediate.

#Three ways URLs break agents

These are stated at the mechanism level — the same repeatable patterns we see reading public storefronts, not measurements of any one store.

#1. Dead URLs after a migration or redesign

Replatforms, theme swaps, and catalog cleanups are where most of the damage lives. The SKU still sells; the address it used to live at is gone. Every place that old URL was known — an agent's memory of your catalog, an older citation, a link on someone else's page — now points at nothing. The agent reaches the 404 and either drops the product or cites the last version it cached, which may show last season's price. You didn't stop selling. You just moved without leaving a forwarding address the machine can follow.

#2. Redirect chains the crawler gives up on halfway

A single clean 301 is fine. What breaks is the chain: the old URL 301s to an interim URL, which 301s to a third, which 302s to the final page. Each hop is a place a crawler or agent can lose the canonical signal or simply stop following. Chains accumulate quietly — one from the last migration, one from the HTTP-to-HTTPS move, one from a trailing-slash rule — until the path from the address an agent has to the page you want it on is three or four hops long. Some agents won't walk it, and the product they were about to recommend evaporates on the way.

#3. Wholesale and trade entry points with no stable URL

Some of the most valuable pages never had a durable address to begin with. A wholesale catalog, a trade-account application, a "request pricing" flow — these often live behind a form or render entirely in JavaScript, with no public, stable URL for an agent to anchor to. There's nothing to cite and nothing to reach. This is the same discovery gap that keeps B2B stores invisible to agents in the first place; we covered the pricing side of it in Magento Shared Catalogs Confuse AI Shopping Agents. A stable URL for the trade door is the prerequisite that makes the rest of that work reachable.

#Why this is the cheapest fix on the list

Every other AI-readiness improvement — schema, seller-authority signals, availability accuracy — sits on top of a URL the agent can actually resolve. If the address is broken, none of that markup is ever read. So the redirect layer isn't just one item on the list; it's the one with the highest leverage per hour of work, because it's the precondition for everything above it.

And it's genuinely cheap. It doesn't touch checkout logic, ERP, or a theme rebuild. It's a map of old addresses to new ones, clean canonicals, and a sitemap that reflects what's actually live. It ships in days, not months. It's the "boring URL work" that quietly decides whether any of the interesting work counts. It's also the discovery layer behind the 5-signal agent-readiness checklist — the plumbing the other four signals assume is already sound.

#The fix, without a rebuild

• A one-to-one redirect map, single hop. Old URL to new, one 301, no chains. Where chains already exist, collapse them so every legacy address reaches the live page in a single move.
• Canonicals that point at the page that's actually alive. Every product and category should declare a canonical URL that resolves, so an agent knows which address is the real one to reach and to cite.
• No soft-404s. A "not found" page that returns 200 tells a machine the page exists when it doesn't. Return a real 404 or 410 for what's gone, and a 301 for what moved.
• A stable public URL for the wholesale or trade door. Give the trade-account and "request pricing" entry points a durable, crawlable address, even when the pricing itself stays behind login.
• A sitemap and discovery surface that match reality. Remove dead URLs from the sitemap and from any llms.txt or feed, so you're not actively pointing agents at addresses that no longer resolve.

Do the boring URL work first. Everything you build on top of it — the schema, the reviews, the entity signals — only counts if the agent can reach the page. If you migrated or re-themed this year, do you know which of your URLs an AI agent is citing wrong right now?

Send one store URL — especially one that recently changed theme or migrated — and we'll run a free async AI-correctness read: we ask live AI agents about your products and send back a named punch-list of exactly which URLs they're reaching wrong or citing stale: luma-e.com/ai-readiness. No call required.