The short answer
An AI assistant cannot recommend a business it cannot unambiguously identify. Publish your name, address, phone, hours and service area as LocalBusiness structured data in server-rendered HTML, keep those facts identical everywhere they appear, and answer each real question in one place in the first forty words.
There is a version of this question that gets asked constantly and answered badly: how do I get an AI assistant to mention my business? The bad answer is "publish more content." The better answer starts one step earlier, with a question the assistant has to settle before it can recommend anyone at all.
That question is: who is this?
Identification comes before recommendation
Schema.org makes the underlying problem unusually clear in its own introductory material. An HTML tag tells a browser how to display something. It says nothing about what the thing means. The example the project uses is the word Avatar: the same string of characters could be a film or a profile picture, and the heading tag around it carries no clue which [1]. A machine reading your page is in the same position with the words on it.
Now apply that to a business page. "Riverside Auto - open late - 506-555-0134" is perfectly clear to a person. To a machine it is a text string that might be a business name, might be a slogan, might be a page about a business rather than the business itself. If the same name appears on a directory listing with a different phone number, the machine now has two candidate entities and no way to decide whether they are one business or two.
That ambiguity is where most recommendations die. Not because a system dislikes you, but because it cannot answer who is this with enough confidence to put your name in front of someone.
What LocalBusiness actually defines
Schema.org defines LocalBusiness as "a particular physical business or branch of an organization," giving restaurants, bank branches, medical practices and clubs as examples [2]. Structurally it is a subtype of both Organization and Place at once, which is why it inherits two useful sets of properties rather than one.
From LocalBusiness itself you get a small set of commercial details: openingHours as a text shorthand, priceRange, paymentAccepted, and currenciesAccepted [2]. The openingHours format is worth knowing because it is compact and strict: days are two-letter codes (Mo, Tu, We, Th, Fr, Sa, Su), times use 24:00 format, ranges use a hyphen, and multiple days are comma-separated. The vocabulary's own example is Tu,Th 16:00-20:00, and a business open every day can be written as Mo-Su [2].
From Organization you inherit the identity core: address, which takes a PostalAddress; telephone; legalName, described as the official registered company name; and areaServed [2][3]. From Place you inherit geo for coordinates, openingHoursSpecification for structured hours, and hasMap [2].
Two of these are quietly the most valuable. sameAs is defined as the "URL of a reference Web page that unambiguously indicates the item's identity," giving a Wikipedia page, Wikidata entry or official website as examples [2]. That property exists purely to solve the disambiguation problem described above. And legalName lets you state the registered name separately from the trading name, which matters if your incorporation documents and your sign say different things [3].
The address is a structure, not a string
Putting your address in as one line of text is the most common half-measure. PostalAddress breaks it into streetAddress, addressLocality (the town or city), addressRegion (described as the first-level administrative division, which for us is the province), postalCode, and addressCountry [4].
The country field has a specific recommendation attached: it is recommended to be in two-letter ISO 3166-1 alpha-2 format, so CA, although a three-letter code or a full country name is accepted for backward compatibility [4]. It is a small detail with a real effect, because "Canada" written in a free-text blob is one more thing to infer and one more chance to infer wrong.
PostalAddress also inherits from ContactPoint, which is where availableLanguage and contactType come from [4]. For a bilingual New Brunswick business, availableLanguage is a genuinely useful thing to state rather than hope somebody notices.
Hours, done properly
OpeningHoursSpecification is described as "a structured value providing information about the opening hours of a place or a certain service inside a place," with opens, closes, dayOfWeek, validFrom and validThrough [5].
Two rules in that definition are worth reading twice. First: the place is open if the opens property is specified, and closed otherwise [5]. Second: if the value for closes is less than the value for opens, the hour range is assumed to span over the next day [5]. That second rule is how you correctly express a kitchen that closes at 01:00, without which the range reads as nonsense.
The validFrom and validThrough pair is the part almost nobody uses and almost every seasonal business needs. A campground open May through October, or a shop with different December hours, can state both sets and give each a validity window, rather than editing the same field twice a year and forgetting once.
If you have no storefront, say so precisely
Plenty of businesses are real, local, and have nowhere for a customer to walk in. Mobile mechanics, contractors, home-based bookkeepers. The temptation is to publish a home address you would rather not publish, or to borrow one.
The vocabulary has a better answer. areaServed is defined as the geographic area where a service or offered item is provided, and it accepts an AdministrativeArea, a GeoShape, a Place, or plain Text [6]. It is used on Organization, Service, Offer and ContactPoint, and it supersedes the older serviceArea property [6]. The schema.org example for areaServed uses a GeoCircle with a midpoint and a radius in metres, which is exactly the shape of "I cover a thirty kilometre radius around Moncton" [6].
Stating a service area honestly is more useful to a machine than a street address you do not really operate from, because the fake address will eventually conflict with something and conflicts are what destroy identification.
Consistency matters more than volume
Here is the part that most advice inverts. Adding a fortieth blog post does very little for identification. Making your phone number the same in all four places it currently appears does a great deal.
Every conflicting record is a reason for a system to lower its confidence that two mentions describe the same entity. Two phone numbers, a legal name on one listing and a trading name on another, a suite number present in one address and absent in another, an old postal code from before you moved: each of these is a small argument that you might be two businesses.
This is why the sameAs property exists at all - it is an explicit statement that this entity and that reference page are the same thing [2]. But sameAs cannot repair contradictions. It can only point at records, and if those records disagree with your page, you have pointed a machine directly at the evidence of your own inconsistency.
The practical order of operations: fix conflicts first, publish markup second, add listings third. Doing it in the other order multiplies the problem.
FAQ markup turns questions into addressable units
FAQPage is defined simply as "a WebPage presenting one or more Frequently asked questions" [7]. The structure underneath it is the useful part. The page carries mainEntity, which indicates the primary entity described in a page [7]. Each entry is a Question - "a specific question, e.g. from a user seeking answers online, or collected in a Frequently Asked Questions document" - which carries acceptedAnswer, expecting an Answer or an ItemList [8]. Question also offers suggestedAnswer for possible-but-not-definitive answers [8].
What this buys you is granularity. Without it, your answer to "do you take walk-ins?" is a sentence in the middle of a paragraph on a page about something else. With it, that question and that answer are a discrete pair with a boundary around them, and a system quoting it does not have to guess where the answer starts and stops.
The vocabulary is also refreshingly honest about its limits. Answer is defined as "an answer offered to a question; perhaps correct, perhaps opinionated or wrong" [9]. Marking something up as an answer asserts nothing about whether it is true. That is your job.
One canonical URL per fact
HTTP has a specific model of what a web page is, and it is worth understanding because a lot of site structure fights it. In RFC 9110, the target of a request is a resource, most resources are identified by a URI, and what actually travels is a representation - information intended to reflect the state of that resource in a format that can be communicated over the protocol [10].
The practical reading: a URL is an identifier for a thing. If your opening hours live on your homepage, your contact page, and a separate hours page, you have created three identifiers for one fact, and any of them can drift out of date independently. Pick one, and link to it from the others.
When you do consolidate, use a real redirect rather than deleting pages. The 301 status code indicates the target resource has been assigned a new permanent URI and that future references ought to use it, and the server should send a Location header with the new address [10]. A 404, by contrast, means the server did not find a current representation for the resource [10] - which is honest, but throws away every link that pointed there.
Markup a crawler never sees is markup you do not have
This is the failure that wastes the most effort, because the site looks correct in a browser.
Follow the HTTP model through. What the protocol transfers is a representation, consisting of representation metadata and a stream of representation data [10]. That stream is the response body your server sent. If your structured data is generated by JavaScript in the visitor's browser after the page loads, it was not in that response. It is not part of the message.
Some crawlers do execute JavaScript before reading a page. Many do not, and you have no way to control which ones visit you. The test costs nothing: open your page, view the raw HTML source rather than the inspector, and search it for your business name and your phone number. The inspector shows the browser's assembled result; view-source shows what was actually sent. If the facts are missing from view-source, render them server-side.
The plumbing that can silently cancel everything
The Robots Exclusion Protocol is specified in RFC 9309, and it is stricter than most people assume. The rules must be in a file named /robots.txt, all lowercase, at the top-level path of the service; it must be UTF-8 encoded and served as media type text/plain [11].
The error handling is where sites quietly disappear. If the server responds with a status in the 400-499 range, the file is treated as unavailable and the crawler may access any resources on the server [11]. But if the file is unreachable due to server or network errors - the 500-599 range - the crawler must assume complete disallow [11]. A robots.txt that throws a server error does not fail open. It closes the whole site.
Two more details worth knowing. Crawlers should not use a cached copy for more than twenty-four hours unless the file is unreachable, so a fix propagates in about a day rather than instantly [11]. And the specification states plainly that these rules are not a form of access authorization, and that listing paths in robots.txt exposes them publicly and makes them discoverable [11]. It is a request to well-behaved crawlers, not a lock.
The honest limit
Structured data cannot rescue a business that has no real information to publish. If your site does not say what you do, where you do it, when you are open, and how to reach you, marking up the absence of those facts achieves nothing. The vocabulary is a way of stating facts precisely; it is not a source of facts.
For a large share of local businesses, the entire gap is basic and boring. Correct hours. One phone number that rings. A street address with the right postal code. A page that says which towns you serve. Getting those four things accurate and consistent will do more than an elaborate markup scheme layered over details that are wrong, because wrong facts published precisely are just wrong facts that are now easier to quote.
So if you are choosing where to spend an hour: if your hours are out of date, fix the hours. Come back to the markup afterwards.
Answer the question first, then explain
One more structural habit, and I will be straight about its status: no standards body specifies this, and I am not going to cite one as if it did. It is a working practice, and the reasoning behind it is the same identification argument as everything above.
A page that opens with a forty-to-sixty-word direct answer to the question in its title gives any system reading it a self-contained, quotable unit. A page that opens with six hundred words of preamble before reaching the answer gives it a paragraph that only makes sense in context, which is much harder to lift and reuse. Same information, different retrievability.
The version of this you can act on immediately: for each of the five questions your customers actually ask, put the answer in the first two sentences of its section, then explain underneath. You will notice this article is built that way, including the block at the top.
What to do this week
Write down five facts on one piece of paper: your exact business name, your full address with postal code, the one phone number you answer, your opening hours, and the area you serve. Then open every place those facts already appear - your homepage, your footer, your contact page, any directory listing you remember creating - and make them match the paper, exactly, character for character.
That is unglamorous work and it is the highest-value hour available to most small businesses. Once the facts agree with each other, publishing them as LocalBusiness markup in server-rendered HTML [2] is a small job on top of a solved problem. Doing it in the other order is a large job on top of an unsolved one.