The structured data and on-page checks a small business site needs for local and AI search
Search engines and answer tools can only work with what your pages actually say, and with the structured data you attach to them. For a small business that wants to be found in a town, and perhaps cited in an AI summary,
Search engines and answer tools can only work with what your pages actually say, and with the structured data you attach to them. For a small business that wants to be found in a town, and perhaps cited in an AI summary, the useful work is narrow: make the identity of the business unambiguous, keep the visible text honest, and mark up the same facts in a format machines already understand.
This is a technical checklist, not a ranking promise. Google's documentation for AI Overviews and AI Mode is explicit that there are no extra requirements and no special optimisations beyond ordinary SEO. The guidance is in AI features and your website.
Start with the words on the page
Structured data cannot rescue a vague page. Before you touch JSON-LD, check the obvious:
- The title element and the H1 name the service and, where it is true, the town or area.
- The first paragraph answers the query in plain English: who you are, what you do, and where.
- The footer or contact block shows the same name, address and phone as the Google Business Profile.
- Opening hours on the page match the hours you actually keep.
- Internal links use descriptive anchors, not "click here".
If those facts are missing or they conflict, fix the HTML first. Markup that invents a phone number or a department you do not have is a policy problem, not a clever shortcut.
LocalBusiness JSON-LD: required and useful properties
Google's Local Business structured data documentation lists two required properties: name and address. The address should be a PostalAddress with as many parts as you can honestly fill in: street, locality, region, postal code and country.
Recommended properties that are useful for a typical UK firm include telephone (with country code), url (the working URL of that location), geo (latitude and longitude to at least five decimal places), and openingHoursSpecification.
Google also documents aggregateRating and review, but only for sites that collect reviews of other local businesses. Do not mark up reviews you hosted about yourself as if you were a third-party review site.
A minimal, fictional example looks like this. The business is invented; do not copy the coordinates or the phone number onto a live site.
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Riverbank Bookkeeping",
"url": "https://www.example.com/",
"telephone": "+44 1225 000000",
"address": {
"@type": "PostalAddress",
"streetAddress": "1 Example Street",
"addressLocality": "Bath",
"addressRegion": "Somerset",
"postalCode": "BA1 1AA",
"addressCountry": "GB"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 51.38100,
"longitude": -2.35900
},
"openingHoursSpecification": {
"@type": "OpeningHoursSpecification",
"dayOfWeek": [
"Monday",
"Tuesday",
"Wednesday",
"Thursday",
"Friday"
],
"opens": "09:00:00",
"closes": "17:00:00"
}
}
Use a more specific subtype where it fits, such as AccountingService, Dentist or Restaurant. The subtype must match the business. A marketing firm is not a restaurant.
Place the JSON-LD in a <script type="application/ld+json"> block on the page that represents the business, usually the homepage or a contact page. Keep one canonical description of the location. Do not emit three slightly different objects on three templates.
The markup must match the visible page
Google's structured data guidelines ask you to mark up content that is on the page. If the JSON-LD says the shop closes at 17:00 and the footer says 18:00, you have given two answers. The same rule applies to the trading name, the street address and the telephone number.
A practical test is to print the JSON-LD and the visible contact block side by side. Every required value in the markup should be readable by a person who has JavaScript turned off, or at least visible in the rendered page. Generating the object in the client only, after a delayed fetch, is a common way to discover that Google fetched an empty page.
Validate with Google's Rich Results Test, then use URL Inspection in Search Console on the live URL. Fix critical errors. Non-critical warnings are worth reading, but they are not a reason to stuff extra fields you cannot stand behind.
FAQ markup is no longer a Google rich result
Many older checklists still tell you to add FAQPage schema in order to win an expanded result under the blue link. That feature has gone. Google's Search documentation updates state that the FAQ rich result is no longer shown in Google Search results, and that the documentation for it was removed after an announcement in May 2026. See the Search documentation updates.
Visible frequently asked questions can still help a human reader, and they can still give an answer tool a short passage to quote. Write them as ordinary HTML. Do not add FAQ schema in the hope of a rich result that Google no longer displays.
On-page checks that still matter for AI features
Because Google says ordinary SEO is what supports AI Overviews and AI Mode, the unglamorous checks remain the right ones:
- The URL returns 200, is reachable without a login, and is not blocked in
robots.txtor by anoindextag. - There is a single, self-consistent canonical URL.
- The page is readable on a narrow mobile screen, and the main text is in the HTML, not locked inside an image.
- Headings follow a simple order: one H1, then H2s for the sections a person would scan.
- Important claims are specific and, where they include a figure, sourced. Answer tools copy confident unsourced numbers.
- The organisation is named the same way on the page, in the markup, and on the Business Profile.
If you also care about other answer engines, the same clarity helps. So does not blocking the crawlers you have chosen to allow. Which crawlers to allow is a business decision, not a hidden ranking lever.
For a worked view of how this local and AI work sits together on a small-business site, see Click Katha's pages on local SEO services and AI SEO services.
A short test list before you call the page done
- View source and confirm a single
LocalBusiness(or a more specific subtype) JSON-LD object is present. - Check that
nameandaddressare present and that they match the visible contact details. - Confirm latitude and longitude, if you include them, have at least five decimal places and point at the right premises.
- Run the Rich Results Test and save the result.
- Inspect the live URL in Search Console once Google has recrawled it.
- Search the trading name and the main town in Google and compare the Business Profile, the organic page, and the address on the site. They should agree.
None of these steps makes an Overview cite you, and none of them buys a map-pack position. They do stop the usual technical reasons a genuine local page is hard to trust: missing identity, conflicting hours, leftover FAQ markup aimed at a feature that has been withdrawn, and structured data that describes a different business from the one on the screen.
Written by Anish Jha at Click Katha Digital Marketing Agency, a local SEO agency in Farnborough, Hampshire.
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.