Your next website rebuild will settle your AI visibility, probably before anyone says “AI”
Most franchise website rebuilds I’ve seen have a slide near the back of the kickoff deck that says something like “SEO and discoverability: post-launch.” It’s usually sitting right before timeline and budget. Nobody objects. It sounds responsible. Get the thing built, get it live, then optimize.
I get it. A rebuild is a huge lift. There’s a brand refresh riding on it, a new booking flow, new photography, and some franchisee portal feature people have been asking for since before the last rebuild. Discoverability feels like tuning, the kind of thing you do once there’s traffic to look at.
The trouble is that the decisions that determine whether an AI assistant can read your network at all aren’t tuning. They’re architecture. They get made in the first month or two, by people who were never in a discoverability conversation, for reasons that have nothing to do with discoverability.
These are the ones I mean:
- How location pages get made. Is there a real page for each unit with its own address on the web, or is “the location page” a filtered view of a directory that only exists after somebody types in a zip code?
- Where the content lives. Is the name, address, and hours in the page the server actually sends, or does it get pulled in by the browser after the page loads?
- Whether each location describes itself to machines. Structured data is the small block of code on a page that tells a machine “this is a business, here’s its name, address, hours, what it offers, and how to book.” Does every location page carry its own, or is there one brand-level block on the homepage and nothing underneath?
- How the URLs are built, and whether they’ll survive the next time someone swaps the content management system.
A person browsing the site never sees the difference on any of those. A lot of the crawlers behind AI assistants don’t run the JavaScript a browser runs, so when the details get assembled after load, what they get is a pretty shell with a logo on it and not much else. (I want to be careful here. The crawlers change, and a few do render. But I wouldn’t plan a network’s visibility around the generous ones.)
Every one of those choices gets made in design and development, mostly by default, mostly by whatever the template does. And every one is expensive to undo after launch, because undoing it means rebuilding the template that every location page sits on.
So it plays out like this. The brand launches. The site looks better than the one it replaced, and for humans it really is better. Six months later somebody in marketing asks an assistant for the nearest location in their own market, the brand doesn’t come up, and a project gets opened to “improve AI visibility.” Whoever picks it up pulls the location pages the way a machine does, with no browser, and has to give the honest answer: the ceiling got set during the rebuild. There’s real work you can do underneath it, but nobody optimizes their way past a template.
I check a lot of franchise sites this way, and the thing that keeps showing up is that the gap has very little to do with budget. Location pages that are beautiful in a browser and close to empty to anything that isn’t one. Brand-level structured data at the top of the site, nothing per location, hours and address loaded in after the fact. I don’t usually blame the agency for that. The brief never asked.
Franchise brands get hit harder than most, for two reasons.
First, the rebuild is the window. It comes around once in a long while, and it’s the one time the budget exists to change how pages are generated. If machine legibility misses this one, it waits for the next one.
Second, the pages that matter most get built last. For local discovery, the location page is the storefront. Somebody asks for the closest option, and the assistant needs a specific unit to point to. The homepage can’t answer that question. And yet in most project plans I’ve seen, the location template gets done at the end, cheap and fast, after the homepage went through three rounds of review with leadership.
One caution so nobody over-reads this. Being readable doesn’t get you picked. Structured data and clean location pages make a unit eligible to be recommended. Reviews and what people say about you on third-party sites decide whether you’re the one that gets named. A rebuild settles the first part and does nothing for the second. But eligibility comes first, and the rebuild is the cheapest moment you’ll ever get to fix it.
The move is small. Put machine legibility in the brief, right next to the brand guidelines, before anyone opens a design file. Then ask one question at every review: can something with no browser see each location’s name, address, hours, what it offers, and a way to book? Don’t take a yes on faith. Have the agency show you on the staging site, with the browser out of the picture.
If you’re already mid-rebuild, it’s not too late. It just gets more expensive every sprint.
If you’re scoping one now and want a second set of eyes on the brief before the mockups start, that’s what The AI Storefront Audit is for.
If this was useful, Systemwide sends the next one to your inbox. About once a week: a few paragraphs from me and a link to the full piece.
