Do Directory Profiles Help AI Search? Mine Backfired First
I set up directory profiles so AI assistants could check me. Claude started citing them instead of my site, then used them to say I have no reviews.
The client whose site I migrated in September 2026 found me through Grok. He asked it a question in my field, it named two providers, I was one of them, and he emailed me. That’s recorded in my own notes as the attribution, because he told me on the call.
Which means I spent a fortnight rebuilding the site of somebody who hired me because of an AI citation, on a domain that has hundreds of pages old enough and specific enough to be cited the same way.
That reframed what the risky part of the migration was.
Everyone migrating a site knows to protect the rankings. You inventory the URLs, you map the redirects, you keep the titles, you watch Search Console for coverage errors, and if something drops you can see it drop.
The feedback loop works. Search Console will tell you a page 404s. It’ll tell you impressions fell. There’s a dashboard, a date, and a graph with a cliff in it.
AI surfaces give you none of that.
An assistant that cites your site cites a specific URL. It either resolves or it doesn’t, and there’s no report anywhere that tells you it stopped.
Four things go wrong in a migration, in rough order of how often I see them:
The URL changed. Someone tidied /carpal-tunnel-syndrome/ into /conditions/carpal-tunnel-syndrome/ because it’s a better structure. It is a better structure. It also breaks every citation pointing at the old one unless the redirect is there, and unlike a search engine, nothing comes back to re-crawl and forgive you on a schedule you can predict.
Two pages got merged. This is the one that has no redirect fix. Content consolidation is usually good SEO hygiene, and it’s the most destructive thing you can do to a cited corpus, because the passage that was being quoted no longer exists anywhere. A 301 sends the reader to a page that doesn’t contain the answer they were cited to.
The headings moved. Extraction works on structure. A page that answered a question under an h2 phrased the way people ask it, rewritten into prose with a decorative heading, can stay live and stay ranked and stop being quotable.
The machine-readable files 404. If your site publishes llms.txt, or a feed, or structured data that the page depends on, a build that omits them still produces pages that render correctly end to end. On a launch I did in September 2026, exactly that happened: the generated files were skipped by a build command that ran the framework instead of the project’s build, and llms.txt returned 404 for about an hour on a site whose own pages link to it. I wrote that failure up in Four Ways a Site Launch Lies to You.
The old site had 533 URLs. I crawled and inventoried all of them before a single page of the new site was written: status, final URL, title, description, H1, word count, canonical, indexable, in the sitemap. The new site was fitted to that inventory rather than the inventory being fitted to the new site.
Three rules came out of it.
Consolidation is allowed, but only in one direction. I want to be precise here, because my first draft of this post said nothing gets consolidated during a migration and that was a rule I had not actually followed. This migration retired 58 legacy URLs into the blog index and merged six more into surviving posts.
What separates those from the failure above is what was in them. The retired set is almost entirely off-topic local filler that a previous content programme had produced: the best barbecue spots in town, the best boxing gyms, the farmers markets. None of it answers a question about hands or wrists, so none of it can be cited for anything the practice wants to be cited for. The six merges go the other way, folding three near-identical posts about food and joint pain into the one that covers it properly.
The rule I would write down is narrower than “never consolidate.” Do not merge or retire a page that answers a question in the subject you want to be known for. Everything else is fair, and a migration is a reasonable moment to do it, because you are rebuilding the redirect map anyway. What you cannot do is discover afterwards that the page you folded away was the one being quoted.
Every legacy URL resolves, and the redirects preserve the query string. After cutover I sampled 40 rules against the live domain and checked both the status and the target. Query-string preservation matters for a different reason, which is that it carries the advertising click identifiers, and I’ve written that up separately in A 200 Is Not Proof.
Old media URLs resolve too. Images embedded in other people’s pages and in years of syndicated content are citations of a sort. The forced media redirects on this site land on the preserved originals, so they still resolve.
You can’t query most of these surfaces directly, so the check is indirect, and it’s a short one.
Ask three or four assistants the questions your best pages answer, and write down every URL of yours they cite. That list is your real exposure, and it’s usually a different set of pages than your top-ranking ones, skewed toward older content that answers a specific question and away from the commercial pages you’d protect first.
For Copilot there’s one partial exception. Bing Webmaster Tools’ AI Performance report lists a sample of the pages Copilot cites, so add those to the list. Read its counts with care, because they swing hard week to week, and I’ve misread a drop in mine before.
Then look at your referrer data for assistant hostnames, and look for traffic to pages you’d forgotten about. On the migration I just did, the pages carrying the most of this exposure were condition articles written years before anyone was optimizing for a language model.
Whatever that list contains, those URLs don’t change, don’t merge, and don’t get their headings rewritten in the same release as everything else.
There’s a fair objection here, which is that assistants re-crawl, indexes refresh, and a correct 301 will eventually be followed by everything that matters.
Probably true, and I would still plan around the gap rather than the steady state. Nobody I’ve asked can tell me how long the refresh takes for any given surface, the pages most likely to be cited are the ones least likely to be missed in your own analytics, and the whole failure is silent. For the cost of an inventory and a redirect map you’d build anyway, the downside of being careful is nothing.
The full write-up of that migration, including the eight ad landing pages and the 51% of conversions I deliberately didn’t move, is in the case study.
If you also run Google or Meta ads to the site you’re migrating, the conversion tracking is the first thing a migration breaks. The free ads audit reads it from read-only access, and I send the write-up within 24 hours. No call.
Before and after a migration, the free What AI says about you template gives you a fixed set of questions to ask the assistants, so you can compare like with like. For how often assistants name a business at all, see my AI answers field report.
See how I check what AI assistants tell people about a business.
I set up directory profiles so AI assistants could check me. Claude started citing them instead of my site, then used them to say I have no reviews.
I re-ran my own AI-visibility audit 30 days after fixing it. Gemini's factual errors about me fell from 7 of 17 answers to 0. Buyer questions haven't moved.
Add me as a read-only user and I'll write the audit myself: 5 to 7 pages, back within 24 hours of access. A home or furniture store can send the store link instead. Rather talk first? A call is open too.