Why Local Entity Relationships Matter
Local entity relationships are the typed connections between your business and everything around it in the world of search: the city and district where you sit, the neighborhoods you serve, the parent company that owns you, the founders behind the brand, the services you perform, and the directories and partners that vouch for you. In Schema.org every one of these connections has a specific property, and LocalBusiness and Organization are the two entity types that anchor almost all of them.
When you mark up relationships with real entities instead of plain strings, you give Google a graph it can reason over. Its ability to resolve your business for queries like "emergency plumber near city hall" or "roofing company that serves the west side" depends on those typed links. A Google Business Profile alone can only carry part of this story, and the rest has to come from your structured data.
These relationships also compound. A consistent parentOrganization across every franchise page helps Google merge branches into one brand. A sameAs list linking your site, your Google Business Profile, and Wikipedia ties all of those surfaces to a single entity. And an areaServed that matches your citations exactly gives you a defendable service-area footprint that no competitor can copy by keyword stuffing.
Local Entity Relationships at a Glance
Scan all checks grouped by category before you start. Click any row to jump to its full explanation below.
| Category | Checklist Item |
|---|---|
| Core Schema Relationships | 1Mark up your location with locatedIn |
| Core Schema Relationships | 2Declare your reach with serves and areaServed |
| Core Schema Relationships | 3State where you physically run the business with operatesIn |
| Core Schema Relationships | 4Anchor proximity with near and locatedNear |
| Business Structure Relationships | 5Link ownership with ownedBy and operatedBy |
| Business Structure Relationships | 6Nest your brand with parentOrganization and partOf |
| Business Structure Relationships | 7Connect your people with foundedBy and founder |
| Service and Offer Relationships | 8Attach your inventory with offers and provides |
| Service and Offer Relationships | 9State your expertise with specializesIn |
| Service and Offer Relationships | 10Describe your work with performsService |
| Reputation and Association Relationships | 11Credential your coverage with reviewedBy |
| Reputation and Association Relationships | 12Declare your network with partnersWith and sponsors |
| Reputation and Association Relationships | 13Mirror your listings with listedOn and membership |
| Geographic Association | 14Narrow your footprint with servesNeighborhood |
| Geographic Association | 15Define city coverage with servesCity |
| Geographic Association | 16Cover wider territory with servesRegion and adjacentTo |
Local Entity Relationships Checklist
Click any item to check it off. Your progress saves automatically in your browser.
Core Schema Relationships 4 items
Mark up your location with locatedIn
locatedIn is the Schema.org property that points from your business to the Place entity that geographically contains it. It works alongside your postal address, so an address in Denver plus a locatedIn reference to the Denver entity reinforces the same fact twice through two different channels. This matters most for businesses inside stadiums, airports, malls, hospitals, university campuses, and historic buildings, where a street address alone is ambiguous.
When the Place you point to carries its own name and a sameAs link to a recognized reference like Wikipedia or Wikidata, you connect your local entity to a larger entity Google already knows well. Google can then resolve queries that mention landmarks, districts, or neighborhoods near that place, and it anchors your maps pin with more confidence than an address string alone would allow.
Add locatedIn only where you can prove the location, and keep the name identical across your Google Business Profile, your citations, and your schema so all three agree. The JSON-LD below shows a LocalBusiness nested inside a Place reference to Denver.
1st step: Confirm the parent Place for your address (city, district, or landmark)
2nd step: Give that Place a stable name and a sameAs URL to Wikipedia or Wikidata
3rd step: Add the locatedIn property to your LocalBusiness object
4th step: Reuse the exact same name on your Google Business Profile
5th step: Validate the markup in the Rich Results Test
Declare your reach with serves and areaServed
serves and areaServed describe the geographic reach of your business, and both are read as signals when Google decides which out-of-town queries you qualify for. areaServed is the standard property and accepts a City, a State, a Country, or an AdministrativeArea. serves is the broader property that attaches these same geographic targets.
A plumber based in Asheville but willing to travel across Buncombe County, for example, marks its office address in Asheville and then lists Asheville plus Buncombe County under areaServed or serves. Use the same city names and spellings here that you use inside your service-area pages, your Google Business Profile, and your directory citations, because consistency is what lets Google reconcile them. Do not claim areas you cannot serve, and drop any city where you would refuse a job.
For service-area businesses with no public storefront, a precise areaServed list is the single most important entity relationship you can mark up, since it is the one place Google can read your geography as a typed entity. The JSON-LD below pairs the Plumber type with both serves and areaServed on the same entity.
1st step: List every city and county you genuinely serve
2nd step: Match spellings to your service-area pages and Google Business Profile
3rd step: Attach each as a typed Place, City, or AdministrativeArea
4th step: Consider serves for the same targets to reinforce the graph
5th step: Re-validate after every coverage change
State where you physically run the business with operatesIn
operatesIn tells search engines where your organization actually has operations, staff, or facilities, and it complements areaServed. Consider a coffee roasting company with one tasting room in Portland, Maine: operatesIn should reference Portland, where the machine and the team live, while areaServed or serves can describe the wider territory it ships to. Google uses operatesIn to build your maps footprint and your trust profile in the cities where you physically exist.
Businesses with multiple operating locations should repeat the property or attach an array so each operating city appears explicitly. Keep the names and URLs identical to the entity nodes you use elsewhere on the same page, and where the place has a sameAs link, include it so the reference becomes resolvable. Do not populate operatesIn with cities where you only deliver a product or visit occasionally, reserve it for genuine operational presence with a visible base.
When applied correctly, operatesIn separates your real footprint from your marketing reach, which keeps your Knowledge Graph honest and your local ranking signals trustworthy. The example below shows a roaster with an operatesIn reference to the city where its facility sits.
1st step: List the cities with a physical operation base
2nd step: Exclude cities where you only ship or visit
3rd step: Reference each operating city as a typed Place
4th step: Add a sameAs link where a canonical reference exists
5th step: Keep names identical to the address properties on the same page
Anchor proximity with near and locatedNear
near and locatedNear express spatial proximity between your business and other places, and both are used by search engines to answer local queries that mention landmarks. near is a property of Organization that points to a nearby place, while locatedNear is used on search result pages and disambiguates your position relative to reference points.
A hotel downtown, for example, can mark that it sits near the boardwalk and the old lighthouse, giving Google exact anchor points for a query like "hotel near the old lighthouse". Only include landmarks and civic structures that are genuinely minutes away from your front door, because proximity claims you cannot support look like spam when a user drives to verify them.
Reference each neighbor as its own Place typed entity with a stable name, and where possible add sameAs links to well-known references. Google also uses these relationships when it builds the local packs that accompany landmark searches and when it explains why your business matches a proximity query. The combination of near and locatedNear with honest, verifiable neighbors strengthens the local graph attachments for your entity. The JSON-LD below attaches near and locatedNear to a hotel with two nearby Place entities.
1st step: Pick 2 to 4 landmarks within walking distance
2nd step: Confirm each one is a recognized Place entity
3rd step: Attach near for primary neighbors and locatedNear for the rest
4th step: Add sameAs to the landmark where a canonical page exists
5th step: Remove any landmark that is not genuinely close
Business Structure Relationships 3 items
Link ownership with ownedBy and operatedBy
ownedBy records the legal owner of your business, and operatedBy records who runs or manages it day to day. For an independent restaurant owned by a family hospitality group, ownedBy points to the group entity and operatedBy can point to the same group or to a separate management company. These two properties help Google merge franchise branches and subsidiary brands into parent entities, which keeps your Knowledge Graph clean when your brand name differs from your owner name.
When you add them, link to an Organization with its own webpage, so the ownership structure is verifiable. Use the same owner name and url in your about page, your footer, and any press mentions, because Google cross-references those unstructured mentions against the structured property. Avoid marking yourself as owned or operated by an entity that has no visible presence anywhere else on the web, because an unverifiable owner makes the whole markup look manufactured.
For family businesses the founder often doubles as the operator, so in that case pair operatedBy with founder rather than inventing a separate management company. The JSON-LD below shows a restaurant owned and operated by the same group.
1st step: Identify the legal owner of your business
2nd step: Identify who manages day to day operations
3rd step: Create or reference an Organization entity with a real url
4th step: Attach ownedBy and operatedBy to that Organization
5th step: Mirror the same names in your about page and press mentions
Nest your brand with parentOrganization and partOf
parentOrganization is the property you put on a single location to show which larger group owns it, and partOf is the mirror property you can put on the organization that is itself owned by something bigger. A dental franchise with offices in Austin and Houston marks each office with a parentOrganization pointing to the group, and the group marks partOf pointing to the national partners that own it.
This nested structure is what Google uses to build enterprise entities for multi-location brands, so treat the chain carefully. Every branch must use the exact same name, url, and logo for the parent, or Google will treat two spellings as two different parents. Put the same relationships in your Google Business Profile where the supported fields allow it, and inside your location landing pages that already carry LocalBusiness markup.
The biggest failure here is inconsistency: one office says Bright Smiles Dental Group and another says Bright Smiles, and the entity merge never happens. When the merge does happen, reviews, ratings, and brand signals roll up to the parent, which helps every child location rank. The JSON-LD below shows both directions of the relationship.
1st step: List every business location and its owning group
2nd step: Use the exact same parent name and url on every branch
3rd step: Add parentOrganization to each branch's LocalBusiness
4th step: Add partOf on the group if it is itself owned by a larger entity
5th step: Match this structure across the Google Business Profile records
Connect your people with foundedBy and founder
founder and foundedBy both attach the people who started your business, and either works because Google reads them as equivalent signals. The Person entity you reference should carry the founder's real name, their role, and a link to a profile they control, such as LinkedIn, so the person is verifiable. Why does this matter for local SEO?
For service businesses the founder is often the public face, and Google's local Knowledge Graph regularly pairs a business panel with its founder entity when both are connected by schema and consistent mentions. A bakery founded by Elena Vasquez, for instance, can appear in the entity graph connected to Elena as a Person, and that connection supports search for the founder's name, press articles, and association with the business.
Keep the founder name consistent in your about page, your author bio, and any press coverage, and make sure the schema name matches the name Google has already indexed for that person. Do not mark up a founder who is not a genuine owner, because fabricating person entities wastes a relationship that should survive scrutiny. The JSON-LD below attaches both founder and foundedBy to a Person entity with a LinkedIn profile.
1st step: Confirm the genuine founder with an online presence
2nd step: Create a Person entity with name and jobTitle
3rd step: Add the founder's real LinkedIn or About page as sameAs
4th step: Attach founder and foundedBy to the LocalBusiness object
5th step: Match the name on your about page and author bio
Service and Offer Relationships 3 items
Attach your inventory with offers and provides
offers attaches a commercial Offer to your business, and provides attaches a Service. The two are related but different: an Offer has a price, an availability window, and a location, while a Service is what you actually do and it is type-specific. A repair shop on Main Street, for example, offers a brake service package at 149 dollars and provides certified oil changes as a standing service.
Google reads this pair to understand your inventory of products and services, which feeds your local panels, your menus if you are a restaurant, and the service descriptions that surface in local results. Anchor every Offer with availableAtOrFrom pointing back to your location, and give every Service an areaServed so the service knows where it is valid. Keep prices honest and update them whenever they change, because an Offer with a stale price erodes trust in the markup.
For businesses with many services, structure them as a list of type-specific Service entities rather than a wall of text in one field. Together, offers and provides give Google the two things searchers want your entity to resolve: what you sell and what you do. The JSON-LD below includes an Offer and a Service on the same AutoRepair entity.
1st step: Separate priced products from standing services
2nd step: Put products under offers with real prices and currency
3rd step: Put services under provides with a serviceType
4th step: Anchor offers with availableAtOrFrom to your location
5th step: Add areaServed to services and update prices regularly
State your expertise with specializesIn
specializesIn is a Schema.org property used heavily by medical, legal, and professional services to state their area of expertise. A clinic marks specializesIn the Sports Medicine specialty, and a law practice marks it in Employment Law. When you add it, the entity you point to should be the recognized specialty type, not a made-up string, because the whole point is to connect to a specialty entity Google already understands.
The payoff is that queries like "sports medicine near me" start to associate your clinic with that specialty even before your review profile catches up. Stay narrow and honest: a garage that specializes in brake work should say brake service, not full fleet maintenance it cannot actually perform.
Pair specializesIn with the primary category you chose in your Google Business Profile, since Google reconciles the two and a conflict between them forces a choice it may make in the wrong direction. Professional directories and bar association listings that carry the same specialty strengthen the connection, so keep the wording identical across those surfaces. Used correctly, specializesIn is one of the fastest entity relationships to show an effect, because it matches a user's intent directly to a known specialty. The JSON-LD below shows a medical clinic connecting itself to the Sports Medicine specialty entity.
1st step: Confirm your genuine area of expertise
2nd step: Use the recognized specialty type, not a free-text string
3rd step: Match the Google Business Profile primary category
4th step: Keep the wording the same on directories and profiles
5th step: Stay narrow, do not list specialties you cannot perform
Describe your work with performsService
performsService attaches the specific services your business actually carries out, and it is the property Google reads when it wants to know what you do rather than what you sell. A tax accountant uses performsService on the Small Business Tax Preparation service, and a roofing contractor uses it on the Metal Roof Installation service. Each service should carry its own serviceType, provider pointing back to your business, and an areaServed telling Google where the service is available.
This matters for service-area businesses and for queries that mix a service with a location, because the property creates the exact link between service, provider, and place that those queries need. Keep the service names natural and consistent with the language used throughout your site and your service pages, because Google compares them. Do not mark up services you offer only occasionally or services that belong to a partner: a performed service must be something your own team does.
When you have several, use an array of Service entities with distinct serviceType values, ordered by what matters most to your local business. performedService converts your on-page promises into a machine-readable commitment, and that commitment is what search engines trust when they decide whether to show you for a local service query. The JSON-LD below attaches one performed service to a professional service business.
1st step: List services your own team performs
2nd step: Give each a distinct serviceType value
3rd step: Add provider pointing back to your business
4th step: Add areaServed so Google knows where each service is valid
5th step: Keep service names consistent with your service pages
Reputation and Association Relationships 3 items
Credential your coverage with reviewedBy
reviewedBy attaches an organization or person who reviewed your business, and it pairs naturally with the review property. A restaurant can be reviewedBy the local food critic association and carry a matching Review entity with its own rating. Google will not treat a self-created review as evidence, so only mark reviewedBy when the reviewing organization genuinely exists, has published coverage of you, and is willing to be associated.
The value appears when a trusted local publication reviews you: the relationship links your business entity to that publication's entity, and Google weighs that association when deciding whether you are notable enough for a Knowledge Panel or a prominent local pack position. Keep the reviewer name and url identical to the publication's own About page, and reference the actual article where they covered you.
Do not repeat the same reviewer across dozens of checklist items, because one honest, verifiable association is worth more than many invented ones. For businesses in the hospitality and service industries, these relationships are regularly what separates a business with a rich entity graph from a business with only a bare profile. The JSON-LD below shows reviewedBy paired with a review by the same organization.
1st step: List publications or bodies that have genuinely reviewed you
2nd step: Create an Organization entity for each reviewer
3rd step: Attach reviewedBy to that Organization
4th step: Pair it with a matching Review entity and real rating
5th step: Link the actual article URL in the review content
Declare your network with partnersWith and sponsors
partnersWith and sponsors declare your business network in structured form. partnersWith attaches organizations you collaborate with, such as the vendor you use for weddings if you are an events company, and sponsors attaches causes or events your business funds. Both relationships read as trust signals because Google can look at the partner's website and confirm the connection.
When you use them, every partner must be a real organization that is aware of the relationship and ideally linking back to you, because an unconfirmed partner is flaggable as contrived. Local businesses that sponsor a little league team, a river cleanup, or a chamber event get a double benefit: the sponsor relationship in schema plus the real mentions and links the sponsorship generates.
Use the exact organization names from the partner's own site, and feel free to attach arrays when the network is real. Avoid listing competitors as partners, because Google ignores the relationship and it looks strange in a manual review. These relationships compound with digital PR because sponsorship produces articles that mention your business by name, and the schema simply makes the connection explicit for machines. The JSON-LD below attaches partnersWith and sponsors to one events business.
1st step: List organizations you genuinely collaborate with
2nd step: List causes and events your business funds
3rd step: Use the exact names from each partner's own website
4th step: Attach partnersWith and sponsors to the LocalBusiness
5th step: Ask partners to link back to confirm the relationship
Mirror your listings with listedOn and membership
listedOn and memberOf turn your directory and association listings into typed entity links rather than loose strings. listedOn attaches the platforms where your business has profiles, such as Yelp, TripAdvisor, or the Better Business Bureau, and memberOf attaches the membership programs that host you, such as your local Chamber of Commerce, with the hosting organization and membership number made explicit. These mirrored relationships help Google confirm that its map profile for you matches the versions you control elsewhere.
Keep the names of each platform and association identical to how they appear on their own website, and include the permalink to your actual profile. The membership direction is worth marking up even for businesses with one affiliation because the hosting organization, often a Chamber, already has strong authority that can lend context. Do not list a platform where you have no claimable profile, and never invent a membership number.
Every relationship you mark up here should be verifiable in one click, since the entire directory layer of local SEO depends on Google trusting that your listings are real. The JSON-LD below combines listedOn with memberOf.
1st step: List every platform where you have a claimable profile
2nd step: Attach each profile's permalink as the listedOn url
3rd step: Add memberOf for Chamber and association memberships
4th step: Mark the hosting organization and real membership number
5th step: Skip any platform without a live, claimable listing
Geographic Association 3 items
Narrow your footprint with servesNeighborhood
servesNeighborhood narrows your service area to the neighborhood level, and it is the property to use when your business genuinely works street by street. A home services company that takes jobs in Uptown and Capitol Hill but turns down requests across the river marks each district as its own Place. Search engines use neighborhood-level relationships to answer queries that name districts and to build your relevance for "near me" results that resolve to a district centroid.
Never claim a neighborhood you cannot actually reach. When Google later asks what geographic area you serve, your structured markup is one of the sources it consults, so an inflated neighborhood list produces mismatched expectations every time a user calls. Keep the neighborhood names identical to the ones used by the local government and by Google Maps, because alternate spellings split the signal.
If you serve every part of a district except one block, marking the neighborhood is still honest as long as you decline that block openly. The property is an extension-style relationship in Schema.org terms, but it is widely understood and costs nothing to emit. The JSON-LD below attaches servesNeighborhood to a home services business.
1st step: List the districts where you genuinely work street by street
2nd step: Match names to local government and Google Maps labels
3rd step: Attach each district as a Neighborhood typed Place
4th step: Drop any district you cannot actually reach
5th step: Mirror the list on your service-area pages
Define city coverage with servesCity
servesCity attaches the cities your business actively serves, at full city level, and it is the cleanest geographic declaration for a company that works at city granularity. A fitness trainer with clients in Austin and Round Rock lists both cities explicitly even though the studio address sits in one of them. The property works best when it mirrors what a human user sees on your service pages.
If your site says you serve Austin and Round Rock, mark those same two names in schema, and make sure the same list appears in your Google Business Profile service areas. The benefit of explicit city entities is that queries combining your service with the city name, like "personal trainer in Round Rock", can match you based on this relationship even before you have accumulated local citations in that city.
Do not stretch the list to every city within driving distance, only the ones where you actually deliver work and where your team will show up. City entities should carry stable names with no abbreviations, so Austin rather than ATX, and the signal weakens when the same city is written differently across your site and schema. The JSON-LD below lists two cities under servesCity.
1st step: List the cities where your team actually delivers work
2nd step: Use full official city names with no abbreviations
3rd step: Attach each city as a City typed Place
4th step: Match the Google Business Profile service areas exactly
5th step: Re-check the list whenever coverage changes
Cover wider territory with servesRegion and adjacentTo
servesRegion and adjacentTo cover the geography beyond a single city. servesRegion attaches a wider territory such as a county or state, and adjacentTo places your business next to a recognizable geographic neighbor. A landscaper with a yard near the state forest can state that it serves the surrounding region and sits adjacent to the forest, giving Google both a service claim and a proximity anchor.
Use servesRegion for areas you genuinely cover even if the volume is low, and only when you can staff jobs there. adjacentTo should reference real physical neighbors anyone can verify on a map, since Google already holds mapping data for the same places and will cross-check the claim. These two properties together let you capture regional queries that a city-level property would miss, such as "landscapers serving the central county".
Keep every geographic name consistent with the official municipal or state naming, because Google resolves the entity by its canonical name. If your regional coverage is thin, servesRegion should stay small and honest rather than broad and impressive. The JSON-LD below shows a landscaper with servesRegion and adjacentTo on one entity.
1st step: Define the county or state you genuinely cover
2nd step: Attach it as servesRegion with official naming
3rd step: Pick one or two verifiable neighbors for adjacentTo
4th step: Keep names aligned with municipal and state naming
5th step: Shrink servesRegion if coverage is thin or unstaffable
Entity Relationship Tools
Validate your JSON-LD and audit every relationship before you ship it.
Schema.org Validator
Validate your JSON-LD against the official Schema.org vocabulary and catch schema violations or property errors before Google processes them.
FreeGoogle Rich Results Test
Preview how Google parses your entity relationships and confirm that your LocalBusiness properties are detected and understood correctly.
FreeJSON-LD Playground
Paste and expand your JSON-LD in a readable tree view, ideal for debugging nested entity graphs and @id references across relationships.
FreeMerkle Schema Markup Generator
Generate clean LocalBusiness and Organization JSON-LD with entity relationship fields without hand writing the boilerplate every time.
FreeRelated Checklists
Keep exploring the local SEO series. Every checklist follows the same structure.
Local Business Entity
The core entity itself: name, type, and the attributes Google uses to identify who you are.
Local Schema Markup
The full LocalBusiness vocabulary and when to use each type on your pages.
Google Business Profile
The entity layer Google considers authoritative before it trusts your own markup.
Local Citations
The external mentions that confirm and reinforce the relationships your schema declares.
Frequently Asked Questions
Local entity relationships are the explicit connections between your local business and other entities in Schema.org markup: the city or region you are located in, the areas you serve, the parent company that owns you, the people who founded you, the services you offer, and the directories that list you. Properties like locatedIn, areaServed, operatesIn, ownedBy, and partOf make these connections machine-readable. Search engines combine these relationships with your Google Business Profile, citations, and on-page content to build your local Knowledge Graph entity. The clearer and more consistent you make these relationships, the easier it is for a search engine to associate your business with the right places, services, and partners.
locatedIn tells a search engine which Place entity contains your business. It is read alongside your postal address, so an address in Denver plus a locatedIn reference to Denver reinforces the same signal twice. This matters most for storefront businesses inside stadiums, malls, airports, hospitals, and university campuses, where a plain street address is ambiguous. When you mark up locatedIn with a named Place that has its own sameAs reference, you connect your local entity to a larger, already-recognized entity. That connection helps Google place you on maps, resolve queries like "dentist near city hall", and attribute foot traffic data.
areaServed describes the geographic region where you are willing to deliver or work. operatesIn describes the places where you actually have operations, locations, or employees. A landscaping company can operateIn a single county town where the office sits but serve a wider region from that base. Google uses areaServed to decide whether you qualify for out-of-town queries and uses operatesIn to build your footprint on local maps. For service-area businesses without a public address, a precise areaServed list of cities, ZIP codes, or counties is the single most important entity relationship you can mark up.
Use parentOrganization on the local branch and partOf on the organization that owns it. A multi-location dental group marks each franchise branch with parentOrganization pointing to the group, and the group entity uses partOf when it is itself owned by a hospital system or holding company. Pair both with the same name, logo, and url across every branch so Google merges them into one enterprise entity. This helps enterprise local packs, prevents duplicate entity confusion between branches, and lets Google roll up reviews and rating signals at the brand level.
Schema.org lets you extend types with additional properties, and properties you or your CMS emit are still parsed and indexed as JSON-LD, whether or not the validator marks them as extensions. Standard properties published by the LocalBusiness and Organization types should always be your foundation: areaServed, locatedIn, founder, memberOf, parentOrganization. Extension properties such as servesNeighborhood, servesCity, and servesRegion are widely used in local SEO tooling and reading them costs nothing. Keep them consistent with your official citations and Google Business Profile areas so the Knowledge Graph reconciles them.
Google builds the local Knowledge Graph by merging facts from your Google Business Profile, Schema.org markup, directory citations, and contextual mentions. Every relationship property gives Google another typed link between your business entity and other entities: a City, an Organization, a Person, a Service, a Place. Repeated, consistent relationships across your site and across the web strengthen confidence. sameAs URLs anchor your entity to authoritative sources like Wikipedia and Wikidata. When Google can resolve who you are, where you are, who owns you, and what you serve, it can answer richer queries and show your business in more relevant local results.
Depth beats volume. Start with the properties that describe facts you can prove: locatedIn, address, areaServed, founder, parentOrganization, offers, and sameAs. Add relationship properties only when they are true and verifiable on another page or directory. A relationship you mark up but cannot prove anywhere else can look like spam. For most local businesses, 12 to 16 well-chosen relationship properties across your homepage and location pages are plenty. Each one should point to an entity that itself carries a name, url, and ideally a sameAs link, so the JSON-LD forms a graph rather than a list of strings.