Schema Markup Mistakes That Kill AI Visibility

Most businesses that implement LocalBusiness schema get some version of it right. But "some version" is doing a lot of work — even technically valid schema can actively hurt your AI visibility if the data is wrong, inconsistent, or incomplete in the ways that matter to AI retrieval systems.

We see this regularly in Signal Check audits: a business with schema that still scores poorly. The culprit is almost always one of the same handful of mistakes.

Using the wrong schema type

LocalBusiness is the parent type. But if you're a dentist, you should be using Dentist schema. A law firm should use LegalService. A restaurant should use Restaurant or FoodEstablishment.

The more specific the type, the more information it carries. When Perplexity retrieves results for "best family dentist in Barrie," a Dentist schema type is a stronger signal than a generic LocalBusiness — the markup itself tells the retrieval system this business is exactly what the query is asking for.

Using a generic type when a specific one exists leaves signal on the table. Check the schema.org hierarchy for your business category before defaulting to LocalBusiness.

NAP inconsistency between schema and other sources

Name, Address, Phone — these three fields need to match exactly across every source an AI system might check.

If your schema says "Johnson Plumbing & Heating" but your Google Business Profile says "Johnson Plumbing," and Yelp says "Johnson's Plumbing," you have three different entity identities in the wild. AI models looking for confirmation that you're a real, operating business find conflicting data — and that conflict reduces their confidence in citing you at all.

Pick a canonical business name and use it exactly, everywhere. Then audit all your listings for variations and get them corrected.

A description field that says nothing

The schema description field is one of the primary ways AI retrieval systems understand what your business actually does — and most implementations waste it.

"We're a family-owned plumbing company in Hamilton, Ontario" is technically present but nearly useless. It names one city and no services. Compare that to: "Licensed plumbing contractor serving Hamilton, Dundas, and Ancaster — specializing in emergency repairs, water heater installation, and basement waterproofing."

The second version gives an AI model service types, geography, and customer context. Write the description field like you're writing a one-sentence pitch to someone who's never heard of you, because that's exactly what an AI retrieval system is.

Schema only on the homepage

This is the most common mistake. The LocalBusiness schema block lives on the homepage and nowhere else.

Every service page is a potential citation match for a query. If someone asks "who does EV charger installation in Mississauga" and you have a service page for that, the service page is the relevant document — not your homepage. If that page has no schema, an AI has to work harder to connect it to your business entity, which means it's less likely to cite it.

Add LocalBusiness markup to every major service page. Ideally, add Service schema to those pages as well, with a link back to the parent business entity. This is the structured data equivalent of dedicated service pages — both layers working together.

Service areas listed without city-level specificity

The `areaServed` field exists for a reason. Setting it to "Ontario" or "Greater Toronto Area" tells an AI model almost nothing useful.

A query like "best window installer in Burlington" matches against city-level data. If your schema lists GTA instead of Burlington, Oakville, Hamilton, and Mississauga as separate entries, you won't match the Burlington query with the same confidence as a competitor who listed Burlington explicitly.

Use city names. List every city you actually serve, even if the list is long. This is the structured data equivalent of writing individual location-specific service pages — more specificity means more query matches.

Outdated contact details or hours

Schema data goes stale, and when it does, it contradicts your live data elsewhere.

If your schema has a phone number from three years ago and your GBP has the current one, an AI reading both encounters a conflict about a basic fact. Same problem with hours — if your schema says Monday–Friday 9–5 and your GBP lists Saturday availability, the AI has inconsistent information about when you operate.

Run a schema check every time you change your hours, update your phone number, or move locations. Google's Rich Results Test will show you exactly what your schema is declaring.

Schema that isn't visible in raw HTML

JSON-LD schema needs to appear in the actual HTML source of your page. If your CMS inserts it via JavaScript that requires client-side rendering, many crawlers — including PerplexityBot and GPTBot — will never see it.

Check by viewing your page source directly (Ctrl+U, not the DevTools element inspector). Your schema should appear in a `<script type="application/ld+json">` tag that's visible in the raw HTML before any JavaScript executes. If it's not there in source view, it's not being read by most AI crawlers.

This is a surprisingly common issue with schema plugins that use JavaScript injection instead of server-side rendering.

What to fix first

If your Signal Check technical section flags schema issues, the priority order is: NAP consistency first, then correct schema type, then expand the description field, then add city-level service areas, then extend to service pages.

If your schema is technically valid but your citation rates are low, the description field and service area specificity are the most likely culprits. Both are low-effort changes — and we consistently see Perplexity citation improvement within two to four weeks of re-crawl after fixing them.

If you haven't run a Signal Check yet, it takes about 30 seconds and gives you a clear picture of what your schema is (and isn't) communicating to AI systems right now.