Schema Markup for Guide Websites
Builds guide sites for a livingPublished July 21, 2026Last updated July 26, 202612 min read
- JSON-LD is the recommended format of three supported, and it is a W3C Recommendation rather than a search engine's preference.
- Correct markup buys eligibility, not appearance; the documentation declines to promise a rich result even for a page that passes its own test.
- The vocabulary's local business type describes a physical premises, so a guiding operation uses a general type accurately rather than a specific one loosely.
- Do not mark up content that is not visible to readers of the page, which is the rule plugins break by default.
- A structured data manual action costs eligibility for rich results and does not affect ordinary web ranking.
The vocabulary everybody calls schema markup defines a local business as a particular physical business or branch of an organisation, and gives as its examples a restaurant, a bank branch, a medical practice and a bowling alley.
A boat is none of those. Which is the recurring problem for a guiding operation and, once you see it, the thing that decides how the markup should be written. The good news is that all three documents governing this are public, short and unusually blunt: one defines the vocabulary, one standardised the format it is written in, and one says plainly that correct markup buys eligibility rather than appearance. What follows is those three, and then what a guide's markup should actually say. The rest of this material sits together on the getting-booked hub.
| Question | Settled by |
|---|---|
| What words may I use? | The schema.org vocabulary |
| What syntax do I write them in? | The W3C JSON-LD recommendation |
| What will Google do with them? | Google's structured data guidelines |
Which format, and who standardised it?
Three are supported, one is recommended, and it is a W3C standard.
Google's guidelines state that to be eligible for rich results you must mark up pages using one of three supported formats: JSON-LD, which it labels recommended, Microdata, or RDFa.
JSON-LD is not a Google invention. It is a World Wide Web Consortium recommendation, published in its 1.1 version on 16 July 2020 under the title of a JSON-based serialisation for linked data.
Its own abstract describes JSON as a useful data serialisation and messaging format, and the specification as defining a JSON-based format to serialise linked data, designed to integrate easily into systems already using JSON.
That matters practically because it means the format outlives any one search engine's preferences.
It also means the markup can sit in a single block in the page head rather than being woven through the visible HTML, which is why it is the recommended one.
The specification is published as JSON-LD 1.1 by the W3C.
What does markup actually buy?
Eligibility, and the documentation is emphatic about the distinction.
Google states that using structured data enables a feature to be present but does not make it certain that it will be present.
It says directly that there is no promise your structured data will show up in search results, even where the page is marked up correctly according to its own testing tool.
The reasons it gives are worth reading: the algorithm tailors results to what it judges the best experience, depending on variables including search history, location and device type, and may decide a different feature, or a plain text result, is more appropriate.
It also lists markup that is not representative of the main content, markup that is potentially misleading, markup incorrect in a way the test could not catch, and content referred to by the markup that is hidden from the user.
So the honest framing is that markup removes a reason you cannot appear, rather than causing you to appear.
Anybody selling it as a ranking lever is selling something the documentation declines to claim.
The guidelines are published as Google's general structured data guidelines.
What is a LocalBusiness, in the vocabulary?
Two things at once, which is the interesting part.
The vocabulary places the type in two hierarchies simultaneously: a thing that is an organisation, and a thing that is a place.
Its definition reads that a LocalBusiness is a particular physical business or branch of an organisation, with examples given as a restaurant, a particular branch of a restaurant chain, a branch of a bank, a medical practice, a club and a bowling alley.
Every one of those examples is somewhere you can walk into, which is the recurring difficulty for an operation whose place of business is forty miles of water.
The type carries properties including the currencies accepted, the price range, the payment methods accepted, and opening hours.
Opening hours have a precise format: two-letter day codes, times in twenty-four hour form, ranges joined by hyphens and multiple days separated by commas.
The vocabulary's own usage note records the type in use on between one and ten million domains, based on monthly aggregations of Google's web index dated May 2026.
The type is documented at schema.org.
Why is that definition awkward for a guide?
Because the guidance also tells you to be specific.
Google's specificity rule asks you to use the most specific applicable type and property names defined by the vocabulary.
The trouble is that the most specific type describing a fishing guide does not exist, so the honest choice is a more general one used accurately.
Opening hours are the same problem in miniature. The property expects a weekly pattern, and a guiding operation runs by appointment with hours set by the tide.
An operation that publishes a tidy nine-to-five in its markup has described a business that does not exist, and the quality rules address exactly that.
Leaving a property out is permitted and honest. Filling it with something convenient is neither.
The same tension shows up on the Business Profile, where the platform tells appointment-only businesses not to publish hours at all.
How that plays out there is worked through in the profile setup piece.
What a guide's markup actually needs. Count the blocks worth writing: one describing the organisation, on the home page, carrying name, logo, telephone, website and social profiles; one breadcrumb block on each nested page; and optionally one describing each trip as a service. For an operation with eight pages that is one organisation block, seven breadcrumb blocks generated by the template, and perhaps three service blocks, which is an afternoon of work followed by nothing. Set against that, most guide sites carry either no markup at all or a plugin's default output nobody has read. The eight pages and the afternoon are stated assumptions describing the shape of the work, not measurements, and no figure for rich result appearance, clicks or rankings is asserted anywhere here.
What are the quality rules?
Six, and they are about honesty rather than syntax.
Provide up-to-date information, since Google says it will not show a rich result for time-sensitive content that is no longer relevant.
Provide original content that you or your users have generated.
Do not mark up content that is not visible to readers of the page, with the example given that if the markup describes a performer, the page body must describe that same performer.
Do not mark up irrelevant or misleading content, naming fake reviews and content unrelated to the focus of the page.
Do not use structured data to deceive or mislead, impersonate a person or organisation, or misrepresent your ownership, affiliation or primary purpose.
And specify all required properties for the type, since items missing required properties are not eligible at all.
The review rules that intersect with this are set out in the reviews strategy piece.
Which rule do guides break?
Marking up things the page does not say.
The single most common failure is a markup block that describes a business the visible page never mentions.
A plugin fills in an address the page does not display, hours the page does not state, or a price range nobody wrote.
The guideline is unambiguous: do not mark up content that is not visible to readers of the page.
Google's relevance examples make the same point from another angle, naming a sports streaming site labelling broadcasts as local events, and a woodworking site labelling instructions as recipes.
Both are cases of the markup asserting a category the page does not support.
For a guide the equivalent is a page about half-day trips carrying markup describing a storefront with opening hours.
Writing pages whose visible content matches what you would claim is covered in the blogging piece.
What about duplicate pages?
Mark them all, which is counterintuitive.
The location rule says to put the structured data on the page it describes, unless a specific feature guide says otherwise.
Then it adds something most people get wrong: where you have duplicate pages for the same content, the recommendation is to place the same structured data on all of the duplicates, not only on the canonical one.
That matters for a guide with near-identical town pages, because you cannot know which of them will be selected as canonical.
Marking only the one you consider primary means the markup may sit on the page that never appears.
The better answer, of course, is to make those pages genuinely different so the question does not arise.
But where duplicates exist, mark all of them.
Making the pages differ in fact is the subject of the water and city pages piece.
What happens when it goes wrong?
A manual action, and it is narrower than it sounds.
The guidelines state that a structured data issue can result in a manual action, and define what that means: the page loses eligibility for appearance as a rich result.
Crucially, they add that it does not affect how the page ranks in ordinary web search.
So the downside of bad markup is losing a feature rather than losing the site, which is worth knowing before anybody panics.
They also note that reviews or ratings not written by actual users may result in a manual action, which connects this directly to the review rules.
Manual actions are visible in the relevant Search Console report, which is another reason the verification step matters.
Nothing here is a reason to avoid markup. It is a reason to write it honestly and check it once.
Why verification comes first is set out in the local search piece.
Is there an access rule?
Yes, and it catches people who tidy up their robots file.
The technical guidance says not to block your structured data pages from the crawler using the robots file, a noindex rule, or any other access control method.
That reads as obvious until you consider how many sites block a directory containing templates, partials or a print stylesheet that the markup depends on.
It also interacts with the broader point that a page has to be readable before anything on it can be understood.
Markup on a page the crawler cannot reach is markup that does not exist.
Testing against the live URL rather than pasted code is what catches this, because the test then makes the same request a crawler would.
What that file does and does not do is set out in the search fundamentals piece.
What should a guide's markup contain?
Three blocks, and none of them invents anything.
An organisation block on the home page carrying the business name exactly as it appears everywhere else, the logo, the telephone number, the website and the social profiles you actually maintain.
A breadcrumb block on every nested page, describing the path from the home page down to that page, which the platform names as a feature all sites benefit from.
Optionally a service block per trip type, describing what is offered rather than what is promised.
No opening hours unless they are true, no price range unless the page displays it, no address unless the page shows one.
Every value in the markup should be findable in the visible text of the same page, which is both the rule and a useful discipline.
Then stop, because additional types add exposure rather than reach.
The services those blocks would describe are set out in the services piece.
Does more markup mean more reach?
No, and the completeness rule is narrower than it looks.
The guidance does say the more recommended properties you provide, the higher the quality of the result to users, and that rich result ranking takes extra information into consideration.
Read carefully, that is about the properties of a type you legitimately have, not about adding types you do not.
Its own illustration is that users prefer job postings with explicitly stated salaries and recipes with genuine user reviews, both of which are cases of filling in a type you actually are.
A guiding operation adding an events type for trips it does not schedule, or a product type for a service, is not being more complete. It is being less accurate.
The accurate version of that instruction is to fill in every true property of the one or two types that genuinely apply.
Everything beyond that trades a small possible gain for a real accuracy risk, and the accuracy rules carry the manual action.
Fewer types filled honestly is the whole of the good advice here.
What about markup a booking system adds?
It is still yours, and still your exposure.
Most guide sites carry a booking widget, a review widget or an embedded calendar, and several of those emit their own markup.
That markup describes your business, sits on your page and is judged against your site, whoever generated it.
So the check is the same: view the source, read what it claims, and ask whether the visible page supports it.
A widget asserting aggregate ratings your page does not display, or offers with prices the page does not show, is a stated violation regardless of who wrote it.
Where a vendor's output cannot be edited, the honest options are to configure it properly, to raise it with them, or to remove the widget.
What is not an option is treating it as somebody else's problem, because the manual action lands on your page.
The same principle applies to anything a third party publishes on your behalf, which is a recurring theme across this whole subject.
Where do guide sites go wrong?
Seven ways, and most come from a plugin.
Installing something that emits a default block nobody has read, describing a business that does not match the page.
Publishing opening hours in markup for an operation that runs by appointment.
Carrying an address in markup while hiding it everywhere else, which is a contradiction a crawler can see.
Marking up review ratings that were not left by actual users, which the guidance names as a possible manual action.
Marking only the canonical of a set of duplicate pages, against the explicit recommendation.
Blocking the directory the markup or its assets live in.
And expecting the markup to move rankings, when the documentation says a manual action against it does not even affect ranking.
How to watch for that without obsessing is described in the rank tracking piece.
What do operators not expect?
That the vocabulary has no word for what they do.
Most people assume there is a correct type waiting to be found, and for a guiding operation the closest available describes a physical premises.
The second surprise is that the recommended format is a W3C standard rather than a search engine's format, which makes it durable.
The third is that markup buys eligibility and nothing more, stated in the documentation in almost those words.
The fourth is that a manual action costs the rich result and not the ranking, which is a much smaller penalty than the phrase suggests.
The fifth is the instruction to mark duplicate pages as well as the canonical, which reverses most people's instinct.
Taken together, this is a small, finite, honest piece of work that is routinely oversold.
Which listings and directories deserve similar scrutiny is examined in the directories piece.
How would you check yours?
Four checks, half an hour.
View the source of your home page and find the markup block, then read it as a description of a business and ask whether it is true.
Take every value in it and look for the same value in the visible text of the page, because anything that fails that test breaks a stated rule.
Run the live URL through the testing tool rather than pasting code, so the request matches what a crawler makes.
Open the manual actions report, which requires the site to be verified, and see whether anything is recorded against it.
Anything you cannot justify from the visible page comes out, and nothing needs to replace it.
A shorter honest block outperforms a longer speculative one, because the longer one carries the exposure.
The title and heading work that sits alongside it is in the on-page basics piece.
The markup, in order
JSON-LD, honest values, visible content, then leave it.
Write it in JSON-LD, because it is the recommended format and a W3C recommendation rather than a vendor preference.
Use the most specific type that is actually true, and accept that for this trade the most specific true type is fairly general.
Put an organisation block on the home page and breadcrumb blocks on the nested pages.
Include only values that appear in the visible text of the same page.
Leave out opening hours, price ranges and addresses that would misdescribe the operation.
Mark every duplicate page rather than only the one you think is canonical.
Never block the pages or assets involved from the crawler.
Then test the live URL once, check the manual actions report, and stop.
The ranking picture this feeds into is examined in the map pack piece.
No appearance or ranking figures appear here. Nothing on this page states a rich result appearance rate, click-through effect, ranking change or booking outcome for any site, in any market, and no estimate has been written in where such a figure might belong. The usage range quoted for the local business type is the vocabulary's own published note, dated May 2026 and based on aggregations of Google's web index; it describes how widely the type is used and says nothing about what using it achieves. Google's guidelines were read on 26 July 2026 and are revised without notice, the vocabulary is maintained continuously, and the JSON-LD recommendation dates from 16 July 2020. Nothing here is legal advice.
How this was checked. The general rules are quoted from Google Search Central, General structured data guidelines, at developers.google.com/search/docs/appearance/structured-data/sd-policies, read on 26 July 2026. Quoted from it: that a structured data issue can result in a manual action, that a structured data manual action means a page loses eligibility for appearance as a rich result, and that it does not affect how the page ranks in Google web search, with the Manual Actions report in Search Console named as where to check; that Google does not promise structured data will show up in search results even where a page is marked up correctly according to the Rich Results Test; that using structured data enables a feature to be present rather than making it certain, because the algorithm tailors results to what it judges the best experience depending on variables including search history, location and device type, and may determine that another feature or a text result is best; the further listed reasons, being markup not representative of the main content or potentially misleading, markup incorrect in a way the test could not catch, content referred to by the markup hidden from the user, and failure to meet the guidelines, the feature-specific guidelines, the Search Essentials or the content policies; from the technical guidelines, that eligibility requires one of three supported formats, JSON-LD which it labels recommended, Microdata, or RDFa, and that you must not block structured data pages to Googlebot using robots.txt, noindex or any other access control method; from the quality guidelines, the instructions to follow the spam policies, to provide up-to-date information since a rich result will not be shown for time-sensitive content that is no longer relevant, to provide original content generated by you or your users, not to mark up content that is not visible to readers of the page with the performer example, not to mark up irrelevant or misleading content such as fake reviews or content unrelated to the focus of a page, and not to use structured data to deceive or mislead, impersonate any person or organisation, or misrepresent ownership, affiliation or primary purpose; the relevance examples of a sports live streaming site labelling broadcasts as local events and a woodworking site labelling instructions as recipes; the completeness rule that all required properties must be specified and that items missing required properties are not eligible, with the note that reviews or ratings not by actual users may result in a manual action; the location rule to put structured data on the page it describes and, where duplicate pages exist for the same content, to place the same structured data on all duplicates rather than only the canonical page; and the specificity rule to use the most specific applicable type and property names defined by schema.org. The images section and the multiple-items section of that page were read but are not relied on here. The vocabulary material is quoted from schema.org/LocalBusiness, read on 26 July 2026: the definition of a LocalBusiness as a particular physical business or branch of an organisation, with the examples of a restaurant, a particular branch of a restaurant chain, a branch of a bank, a medical practice, a club and a bowling alley; the two type hierarchies placing it under both Organization and Place; the properties of currencies accepted, floor level and opening hours, with the opening hours format specified as two-letter day codes, twenty-four hour times, hyphenated ranges and comma-separated days; and the usage note recording the type in use on between one and ten million domains, attributed to monthly aggregations from Google's web index and dated May 2026. The page carried a notice that it was serving the development version of the vocabulary. The format specification is quoted from JSON-LD 1.1, a JSON-based Serialization for Linked Data, a W3C Recommendation of 16 July 2020, read at w3.org on 26 July 2026, specifically its abstract describing JSON as a useful data serialisation and messaging format and the specification as defining a JSON-based format to serialise linked data, designed to integrate easily into deployed systems already using JSON. The remainder of that specification was not relied on. The arithmetic panel uses stated illustrative assumptions and contains no measurement. Nothing here is legal advice.
If your booking calendar has more open weeks than you’d like, I’ll build you a free preview of your booking site before you pay a cent.
Get a free website previewMarkup, the three documents behind it, and what it actually buys
Which format should I use?
JSON-LD. Google's guidelines state that to be eligible for rich results you must mark up pages using one of three supported formats, listing JSON-LD as recommended, alongside Microdata and RDFa. JSON-LD is not a Google invention: it is a World Wide Web Consortium Recommendation, published in its 1.1 version on 16 July 2020 under the title of a JSON-based serialisation for linked data. Its abstract describes the specification as defining a JSON-based format to serialise linked data, designed to integrate easily into deployed systems already using JSON. That durability matters, and it also means the markup sits in one block rather than woven through the visible HTML.
What does markup actually get me?
Eligibility, and the documentation is emphatic. It says using structured data enables a feature to be present rather than making it certain, and states there is no promise your structured data will appear even where the page is marked up correctly according to the Rich Results Test. The reasons given include that the algorithm tailors results to what it judges the best experience, depending on variables including search history, location and device type, and may decide another feature or a plain text result is more appropriate. So markup removes a reason you cannot appear rather than causing you to appear.
Is there a type that fits a fishing guide?
Not exactly, which is the recurring difficulty. The vocabulary defines a LocalBusiness as a particular physical business or branch of an organisation, giving a restaurant, a branch of a restaurant chain, a bank branch, a medical practice, a club and a bowling alley as examples, and places the type under both Organization and Place. Every example is somewhere you can walk into. Google's specificity rule asks you to use the most specific applicable type and property names defined by schema.org, so the honest answer for this trade is a more general type used accurately rather than a specific one used loosely.
Should I put my opening hours in the markup?
Only if they are true. The type carries an openingHours property with a precise format: two-letter day codes, times in twenty-four hour form, ranges joined by hyphens and multiple days separated by commas. A guiding operation runs by appointment with hours set by the tide, so publishing a tidy nine-to-five describes a business that does not exist, and the quality rules address exactly that. Leaving a property out is permitted and honest; filling it with something convenient is neither. The same tension appears on the Business Profile, where the platform tells appointment-only businesses not to publish hours at all.
What is the rule guides break most often?
Marking up content the page does not show. The guideline is unambiguous: do not mark up content that is not visible to readers of the page, with the example that if the markup describes a performer, the page body must describe that same performer. A plugin filling in an address the page does not display, hours it does not state or a price range nobody wrote breaks that rule. Google's relevance examples make the point from another angle, naming a sports streaming site labelling broadcasts as local events and a woodworking site labelling instructions as recipes. Every value in the markup should be findable in the visible text of the same page.
What happens if the markup is wrong?
A manual action, and it is narrower than the phrase suggests. The guidelines state that a structured data issue can result in a manual action, that a structured data manual action means the page loses eligibility for appearance as a rich result, and, crucially, that it does not affect how the page ranks in Google web search. So the downside is losing a feature rather than losing the site. They also note that reviews or ratings not written by actual users may result in a manual action, which connects this directly to the review rules. Manual actions appear in the Search Console report, which is another reason verification matters.
Should I mark up duplicate pages?
Yes, and this reverses most people's instinct. The location rule says to put the structured data on the page it describes unless a feature guide says otherwise, then adds that where you have duplicate pages for the same content, the recommendation is to place the same structured data on all the duplicates, not only on the canonical page. That matters for a guide with near-identical town pages, because you cannot know which will be selected as canonical, and marking only the one you consider primary may leave the markup on a page that never appears. The better answer is to make those pages genuinely different so the question does not arise.
Sources & methods
- General structured data guidelines, Google Search Central
- LocalBusiness type definition, schema.org
- JSON-LD 1.1, a JSON-based Serialization for Linked Data, W3C Recommendation 16 July 2020
Every figure here is traced to a named public source and checked against it. Licensing, tax, and fee rules change. Verify your state’s current rules with the agency directly before you count on any number here.
Evan Knox
I build booking websites and run the ads and search for owner-run fishing guides, one operation per stretch of water. My first guide client, Bowman Fly Fishing, grew its revenue 4x in a year from that work. Field Notes is where I put the straight numbers on the business of guiding.
More field notes
You fish. I'll handle the code that gets you found.
I'm Evan, and the technical pieces like schema markup are exactly what I set up for guides. I build booking sites, add the structured data, and run the search and ads for owner-run guide operations, one operation per stretch of water, so anglers find and book you first. Text me at (470) 777-9686 and I'll build you a free preview of your site before you pay a thing.