Why Schema Won't Get You Found in 'Near Me' AI Search

Ask an AI assistant "who's a good plumber near me" and it answers instantly, no crawling, no waiting. That speed is the tell. It means the assistant isn't reading your website at that moment. It's pulling from somewhere else entirely, and understanding where changes what you should actually spend time fixing.

Search for advice on this and you'll find the same list everywhere: claim your Google Business Profile, keep your name, address and phone number identical across every directory, add local schema. That advice is correct. It's also incomplete in a specific way worth naming: almost all of it describes work that happens off your website, on services you don't control, while most tools that talk about "AI readiness", including the one we build, only ever look at your website. This post draws that line clearly: what actually decides whether you show up at all, what a schema tool can and can't do about it, and the practical checklist for the part that's genuinely yours to fix.

What actually happens when someone asks "near me"

OpenAI's own help center explains the mechanism plainly for ChatGPT search: a question like "good restaurants near me" gets rewritten using your general, IP-based location into an ordinary search query, something like "top restaurants San Francisco", which is then handed to a third-party search provider to find results. Nothing in that process is a live read of any individual restaurant's website. The assistant isn't visiting your site, checking your schema, or parsing your page at the moment someone asks. It's running a location-flavored search against an index or a partner data source that already exists, and picking from whatever comes back.

That's a genuinely different question shape from "what does Acme Plumbing do", which an AI assistant answers by drawing on whatever it already knows or can look up about a specific, named entity, your site, your schema, your public presence, all of it fair game. "Near me" doesn't name you at all. It names a category and a location, and something has to decide the candidate list before your name is even in the running. Your website's structured data has no vote in that decision, because nothing reads it as part of making one.

This isn't specific to one company's assistant, either. Google's own AI Overviews and Gemini draw local results from the same Google Maps and Business Profile data that already powers the ordinary local pack, a system that has never taken schema markup as an input for deciding who shows up on a map. Whichever assistant someone is using, a location-shaped question routes through a location-data layer first, and your website only enters the picture afterward, if it enters at all.

Two separate jobs, and only one of them touches your website

Once you split "getting found" into two actual jobs, the confusing part of local AI visibility stops being confusing.

Retrieval: getting onto the candidate list at all. Something, a directory, a maps provider, a review platform, decides who's even eligible to be mentioned for "plumber in [your area]." This step runs entirely on data those platforms hold about you, not on anything living on your own domain.

Description: what gets said about you once you're a candidate. Once a business is in the running, an assistant (or the search layer feeding it) needs facts to describe it correctly and consistently: is this the same "Acme Plumbing" listed three different ways, what's the real phone number, is this the plumber that covers this specific neighborhood. This is where your own website, and its schema, can genuinely contribute a corroborating signal.

Nearly every piece of advice online, ours included, in our own industry-specific guides, bundles these two jobs into one instruction: "keep your name, address and phone consistent across your schema, your Google Business Profile and your page." That's true and worth doing, but it obscures that the consistency check only matters for the second job. You cannot schema your way onto a candidate list you were never being drawn from in the first place.

The retrieval layer: what lives there, and why your schema can't reach it

The platforms that feed a "near me" style answer are the same handful of places local SEO has cared about for years, they just matter more now because more query volume runs through assistants that use them as a data source rather than a full search results page. Depending on your business type, this typically means some mix of:

• Google Business Profile, the free listing tied to Google Maps and the local pack
• Apple Maps (via Apple Business Connect), which powers Siri and Maps results on iPhone
• Bing Places, Microsoft's equivalent, which also feeds Copilot
• Yelp, still a major review and discovery platform in the US
• Industry-specific directories where your category has one: Avvo or Justia for lawyers, Healthgrades or Zocdoc for medical practices, Houzz or Angi for home services, TripAdvisor for hospitality

Every one of these is a separate account, with its own login, its own form fields, and its own review of what you submit. None of it is schema markup. None of it lives on your server. And that last part is the whole reason a website audit, ours or anyone else's, structurally cannot see, verify, or fix any of it: reading a page's HTML tells you nothing about what's sitting in a Yelp business owner's dashboard on Yelp's own servers. A tool built to read your website is, by construction, blind to a system it was never pointed at.

That's not a limitation anyone advertises, because "our tool also can't do the other company's homework" isn't a great pitch. It's still true, and worth saying plainly instead of implying that getting your schema right solves the whole problem.

The description layer: what your own site's schema can actually do

This is the half a tool like ours genuinely reaches, and it's worth being specific about what it covers rather than treating "add local schema" as one undifferentiated task.

If you have a real, visitable location, your schema's job is straightforward: a correct business type, an address block, opening hours, a phone number, all matching what's on your Google Business Profile and everywhere else. Our multi-location guide covers the syntax for anything beyond a single storefront, chains, franchises, and the case below.

If you don't have a public location, a mobile dog groomer, a locksmith who works out of a van, a house cleaning service that covers a whole metro area, you're not supposed to claim one. Schema.org's LocalBusiness type exists for a business customers walk into; asserting an address you don't actually display to the public misrepresents what you are. This is exactly the scoring problem we had to solve directly in our own entity form: a declared service-area business (no public address, has_physical_location set to false) doesn't lose points for the address it correctly never fills in, it earns the equivalent credit by declaring where it actually works, using schema.org's areaServed property, a list of cities, counties or a radius, whichever is true. A service-area business with a clean, honest service-area declaration and no address scores exactly as well on this front as a storefront with a complete one. Neither approach is a workaround, they're both accurate descriptions of two different kinds of business, and our readiness scoring breakdown covers how the rest of that score is built if you want the full picture.

Either way, sameAs is where the description layer connects back to the retrieval layer, at least partially. A sameAs array on your Organization or LocalBusiness schema lists the URLs of your profiles elsewhere: your Google Business Profile, your Yelp page, your social accounts. Our sameAs guide covers exactly which links belong there and how to structure them. What's worth adding here: we canonicalize every URL you paste in, upgrading it to https, stripping tracking parameters, fixing a handful of known apex-domain redirects, so the link itself is clean and consistent everywhere it appears on your site. What that canonicalization cannot do is reach through the link and confirm the page on the other end is accurate, complete, or even still live. A sameAs link to a Yelp profile you abandoned two years ago still validates perfectly. The schema is correct. The listing behind it might not be.

An honest note on how we think about this internally

It's not just customer-facing advice, either. Elsewhere in our own systems, when we pull real numbers for research and case studies, we deliberately filter directory and review sites like Yelp, Angi, TripAdvisor and similar aggregators out of the data entirely, specifically because measuring a business category by what shows up in search is otherwise dominated by the directories, not the actual businesses. We treat "your website" and "a directory that lists your website" as fundamentally different kinds of thing internally too, for exactly the reason described above: they're different data, held by different parties, and conflating them produces the wrong picture whether you're auditing a schema or running a study.

Your off-site checklist

None of this is schema work, and no tool that reads your website can do it for you. It's still the highest-leverage set of tasks for local AI visibility, so it earns a real checklist rather than a one-line mention.

Claim and fully complete your Google Business Profile. Every field, not just name and address: categories, hours, service area if you have no storefront, a real description, and photos. An unclaimed or half-filled profile is often worse than none, it's a candidate entry with almost nothing for anything downstream to describe you with.

Set up Apple Business Connect and Bing Places. Both take under fifteen minutes once your Google profile is done, since most of the same information carries over, and both feed assistants your Google listing never touches.

Claim the two or three directories that actually matter for your category, not every directory that will take a free listing. A roofer needs Angi and Houzz far more than a generic business directory nobody in that trade actually searches.

Make your name, address and phone identical, character for character, everywhere. "123 Main St." on one profile and "123 Main Street" on another is a mismatch a matching system has to resolve, and it won't always resolve it in your favor. Pick one canonical form and paste it everywhere, including your own schema.

Keep every profile current when anything changes. A moved location, a new phone number, or seasonal hours left stale on even one platform is the kind of small inconsistency that undermines confidence in every other listing that's actually correct.

Common mistakes

Assuming "add schema" covers this. Schema markup is real, useful work, and it addresses none of the retrieval question. If nobody has claimed your Google Business Profile, no amount of correct JSON-LD changes who gets considered.

Claiming a location you don't have. Marking up a public address for a service-area business that doesn't take walk-ins misrepresents the business and can get a Google Business Profile suspended for an address violation. Declare your service area honestly instead.

Treating directories as a one-time setup. A profile claimed once in 2023 and never revisited drifts out of sync with reality: old hours, an old phone number, a closed location still listed as open. Review every profile you've claimed at least twice a year.

Letting one directory disagree with the rest. A single wrong address on one minor directory can be the one a matching system flags as inconsistent, dragging down confidence in the profiles that are actually correct.

Ignoring category-specific directories entirely. General-purpose visibility work (Google, schema, your own site) misses the platforms an assistant might specifically lean on for your category, a legal directory for an attorney, a hospitality directory for a restaurant.

A self-check you can run today

List every place you're listed. Search your business name plus your city. Note every directory, map service and review platform that returns a result, including ones you don't remember claiming.

Put your name, address and phone from each one side by side. Even small formatting differences count. Write down every mismatch you find.

Ask an AI assistant a real "near me"-shaped question about your own category and area, not your business name. "Who's a good [your trade] in [your neighborhood]" is closer to how a real customer asks than "tell me about [your business name]." If you don't appear at all, that's a retrieval-layer problem, work the checklist above. If you appear but something's described wrong, address, hours, service area, that's a description-layer problem, and it's the one your own schema can help fix.

How to check and fix

Start with retrieval. Confirm you're claimed on Google Business Profile, Apple Business Connect, Bing Places, and the one or two directories specific to your category. An unclaimed profile is a bigger gap than any schema issue.

Then align every profile's core facts, name, address, phone, hours, service area, to one canonical version, and update your own site's schema to match exactly.

Then run a structured data crawl of your own site to confirm your LocalBusiness or Organization schema (whichever fits, see our type guide if you're not sure) and your sameAs links are present, valid, and pointed at the profiles you just cleaned up.

Repeat the self-check every few months. Directory information drifts on its own, a platform changes its form fields, a review gets flagged, a listing gets auto-merged with a duplicate. This isn't a one-time project.

AI Schema Gen keeps the description layer, your site's LocalBusiness or Organization schema, and your sameAs links, accurate and consistent automatically. Start free or see the local business guide for the full setup.