One Livery, Five Landings: The Entity Google Can't Quite Place
Updated: Sep 8
A river livery's real footprint rarely matches its schema markup. The website lists one address -- the shop, the office, the barn where the trailers live -- while the actual service happens at a scatter of put-ins and take-outs that might span fifteen or twenty miles of river, none of which is the address on the homepage. To a human reader who already understands how a livery works, that gap is invisible. To a search engine or an AI system trying to resolve what this business is and where it operates, it's a genuine ambiguity.
That ambiguity has real consequences. When someone asks an AI assistant "is there a canoe livery near [put-in name]" or "where do I put in for the float from X to Y," the system is trying to match a specific place to a specific business entity. A livery whose only structured location is a shop address ten miles from the river doesn't resolve cleanly to that query, even if the livery in fact runs shuttles to and from that exact put-in every day of the season. A river-guide directory that lists access points as plain data rows -- however thin the rest of its content is -- wins that specific resolution by default, simply because it named the place and the operator's own site didn't.
This post covers how to structure a multi-access-point livery as a single, coherent business entity with its access points named and disambiguated, rather than either pretending the business is a single-point storefront or leaving the access points as unstructured mentions buried in trip-description paragraphs. It's foundational to the rest of this cluster -- the segment landing pages, the water-level content, and the Google Business Profile structure covered elsewhere all depend on this entity being defined clearly first.
Why a Single-Address LocalBusiness Record Undersells the Real Footprint
Schema.org's LocalBusiness type -- the foundation most livery sites already use, even if unknowingly, through a website builder's default markup -- is built around the assumption of one primary address where the business is located and, implicitly, where it's found. That works fine for a business that genuinely operates from one point. It works poorly for a livery, whose actual value to a customer has almost nothing to do with the shop address and everything to do with which stretch of river they can access and where.
The practical result is that most livery sites, even good ones, have a single LocalBusiness record naming the shop and then describe the actual river access points only in prose -- "we run trips from Route 9 down to the Route 40 bridge" -- with no structured data attached to either location. A search engine can read that sentence, but it can't easily treat "Route 9" and "the Route 40 bridge" as places with their own identity, distance, and relationship to the business the way it can treat a structured address.
The fix isn't complicated conceptually, even if it takes real work to implement: define the business's areaServed to reflect the actual river corridor it operates on, and represent each real, regularly-used access point as its own named place, connected back to the parent business. That gives a resolving system the two things it needs -- confirmation that this business operates across a defined stretch, and specific, named points within that stretch it can match a location-specific query against.
The Practical Structure: Parent Entity Plus Named Access Points
A workable model treats the livery itself as the parent LocalBusiness entity -- name, phone, primary contact address (the shop, if there is one), and a description that states plainly what kind of business this is and the general river corridor it serves. On schema.org specifically, LocalBusiness, TouristAttraction, and BoatRental are the type candidates worth checking against schema.org's current definitions at build time, since a livery can reasonably sit under more than one depending on whether the site is emphasizing the guided-access side of the business or the rental side. The properties worth using regardless of which base type fits best are `areaServed`, to state the river corridor as a whole, and `hasMap`, paired with a distinct Place entity for each real access point. Beneath that parent entity, each real, regularly-used put-in and take-out gets represented as its own named Place: a specific label (not just "put-in #1" but the actual name people use locally -- a bridge, a landing, a park), a location with as much geographic specificity as is reasonably available, and a clear relationship back to the parent business as one of its service locations.
This doesn't require inventing a fictional multi-location business structure the livery doesn't actually have -- it's still one business, one entity, one point of contact. What changes is that the entity's markup now reflects the geographic reality of how the business actually operates, rather than compressing a river corridor down to a single pin on a map that undersells the whole operation.
It's worth being disciplined about which access points actually make this list. A put-in used once a season for a special trip doesn't need the same structured treatment as the five or six landings the business runs from every week during the season. Listing only the real, regular access points keeps the entity accurate and avoids the appearance of overstating the business's footprint -- accuracy here matters more than exhaustiveness.
What This Fixes for the Segment and Water-Level Content Elsewhere in This Cluster
Once access points exist as named, structured entities rather than prose mentions, the segment-specific landing pages covered elsewhere in this cluster -- one page per real put-in-to-take-out route -- have something concrete to attach to. Each landing page can reference its specific put-in and take-out as the same named places defined in the entity structure, rather than each page inventing its own loose description of the same physical location. That consistency is exactly the kind of repeated, corroborating signal that helps a resolving system build confidence in what a place actually is and which business operates there.
The same is true for water-level and conditions content: a page discussing floatability at a specific stretch of river is more useful, and more citable, when it can reference the actual named put-in and take-out that stretch runs between, rather than a vague "our river" description. Entity clarity at the foundation makes every other piece of content built on top of it more specific and more useful.
This is also where a multi-access-point livery starts to look structurally similar to a business with several physical locations, even though it's legally and operationally one business. That's a useful frame for thinking about the markup: the goal is the same clarity a customer would want from a five-location retail chain, applied to a business whose "locations" are landings on a river rather than storefronts on a street.
What Not to Invent Here
This post deliberately doesn't publish a specific schema.org property-by-property syntax template, because the correct implementation depends on the specific platform a given livery's site runs on and the exact number and names of that operator's actual access points -- publishing a generic code sample here risks it being copied verbatim onto a site where it doesn't actually match reality. It's also worth being precise about the type names: LocalBusiness, TouristAttraction, and BoatRental are the candidates worth checking against schema.org's current definitions at the time markup is actually built, not treated as a fixed, permanent list -- schema.org's type definitions do get refined over time. There is no Google-endorsed or officially sanctioned "multi-put-in" schema type, and nothing about using `areaServed` and `hasMap` with multiple Place nodes should be described as an official Google program or partnership -- it's a documented, general-purpose way to structure location data, applied to this specific business shape. The concept -- parent entity, named access points, consistent relationship between them -- is what matters; the exact markup should be built against a specific operator's real access points, verified against what that operator actually runs, not assumed from a template.
It's also worth being direct about what structured markup does and doesn't do. Marking up access points correctly removes ambiguity about what the business is and where it operates -- it doesn't buy placement, guarantee an AI citation, or promise a ranking outcome. The value is in giving a resolving system accurate information to work with, not in gaming a result. Any claim that a specific schema change guarantees a specific search or AI-citation outcome should be treated skeptically, including from this post.
A Simple Audit to Run Before Building Anything
Before touching markup, list every access point the business actually uses on a regular, current basis -- not historically, not occasionally, but the put-ins and take-outs a customer booking today would actually be shuttled to or from. For each one, note: the name people locally and practically use for it, its general location (address, cross streets, or a landmark description precise enough to be useful), and which trip segments or routes actually use it.
Cross-check that list against what currently appears anywhere on the website -- trip pages, a map graphic, an about page -- and note where the site's existing prose descriptions are vaguer or less specific than the actual list. That gap is usually the clearest evidence of where entity ambiguity is currently costing the business a chance to be matched to a location-specific query.
Finally, check whether the business's Google Business Profile, if one exists, reflects the same access points consistently -- this connects directly to the Google Business Profile structure covered elsewhere in this cluster, since a mismatch between what the website's entity structure says and what the Google Business Profile says is its own source of confusion for a resolving system trying to reconcile the two.
Related Reading
More for operators building the same kind of page -- clays courses and dove outfits that need a specific answer, not another brochure paragraph.
What Answer Engines See in the Off-Season: The Shoulder-Month Gap
Scout Troops Aren't a Booking Problem -- They're a Citation Problem
The Shuttle Fleet Is Marketing Infrastructure, Not Just Logistics
Insurance Talk Without the Legal Risk: A Trust Page That Holds Up
What the Airboat Is Actually For: Marsh Access, Not Nature Tourism
Rental Livery or Guided Outfitter? Why AI Keeps Confusing the Two
One Business, Five Landings: Making Google Business Profile Tell the Truth
Frequently Asked Questions
Why does it matter if my river livery's schema only shows one address?
Because a resolving AI system or search engine uses that address as its primary understanding of where your business operates, and a livery's real value is tied to river access points that may be miles from that address. A single-address entity undersells a multi-landing operation and makes it harder for the system to match your business to a location-specific query about a put-in or take-out it doesn't know you use.
Do I need to create a separate business listing for each access point?
No -- this is one business with multiple service locations, not several separate businesses. The structure should represent one parent entity with named access points connected back to it, similar in spirit to how a business with several physical locations is structured, but without implying the access points are independent business entities.
Which access points should actually be included in this structure?
Only the real, regularly-used put-ins and take-outs your business currently operates from -- not every point that's ever been used historically or for a one-off trip. Accuracy and currency matter more than listing every possible location.
Can you give me the exact schema.org code to copy onto my site?
Not responsibly in a general post like this one, because the correct implementation depends on your specific website platform and your specific, real access points. The concept -- parent entity plus named, connected access points -- is what to build toward; the exact markup should be built against your actual current locations, ideally with someone verifying it matches reality before it goes live.
Will fixing this guarantee we show up in AI search results for our river?
No single structural fix guarantees a citation or ranking outcome, and any claim that it does should be treated with skepticism. What accurate entity structure does is remove ambiguity about what your business is and where it operates, which is a precondition for being a plausible source -- not a guarantee of being the chosen one.
How does this relate to our Google Business Profile?
They should tell the same story. If your website's entity structure names five access points but your Google Business Profile shows only the shop address, that inconsistency is itself a signal of an unclear entity. The Google Business Profile side of this problem is covered in more tactical detail elsewhere in this cluster.
What if we only have one put-in and one take-out, not five or six?
Then the ambiguity this post addresses is smaller, but the same principle still applies: make sure both the put-in and the take-out are represented as specific, named places connected to your business, rather than folded entirely into prose description with no structured location behind either one.
Should we mark up seasonal or rarely-used access points the same way as our main ones?
Generally no -- reserve the full structured treatment for access points you use on a regular, current basis. A seasonal or one-off point can still be mentioned in prose without necessarily getting the same structured entity treatment, to avoid overstating your regular footprint.
How often should this entity structure be reviewed?
At least once a season, and any time an access point is added, dropped, or moved -- a river's usable put-ins and take-outs do shift over time due to access agreements, water conditions, or landowner changes, and an entity structure describing a point you no longer use is its own kind of inaccuracy.
Which schema.org type should a livery actually use -- LocalBusiness, TouristAttraction, or something else?
LocalBusiness, TouristAttraction, and BoatRental are all worth checking against schema.org's current definitions when markup is actually built, since a livery can reasonably fit under more than one depending on whether the site emphasizes guided access or equipment rental. There's no single officially mandated type for this business shape, and no Google-endorsed 'multi-put-in' type -- the choice should be verified at implementation time rather than assumed from an older post or template.
Work with Pine & Marsh
A livery that operates across five landings but shows Google a single storefront pin is asking to be matched to the wrong place, or no place at all.
Getting a multi-access-point entity structured correctly is exactly the kind of technical foundation 44 Recreation Agency's SEO & Topical Authority service builds before any content goes live -- and it's the foundation the rest of this cluster's landing pages and local-search work depend on. Start that conversation at pineandmarsh.com/contact. What you've built deserves to be found.
Comments