The Google Business Profile is the foundation, but the website is the reinforcing layer. A profile with a strong location page on the linked website ranks meaningfully better than the same profile with a weak or absent one — Google cross-references the profile against the page and uses agreement as a confidence signal. This chapter covers the location-page anatomy, the schema stack, and the entity reinforcement that makes the GBP signal compound instead of cap.

“Local on-page is where the profile signal either compounds or stalls. Two businesses with identical GBP optimization will rank differently if one has a real, content-rich location page and the other links the GBP to a homepage. The on-page work is the multiplier on everything in the rest of the cluster.”

Location page anatomy

A location page is a dedicated URL — typically /locations/[city]/ or /[city]/ — that exists for one purpose: to be the canonical web destination for that physical location. The required elements:

• H1 with the location name. "Joe's Bakery — Brookline" or "Boston Office" — specific, unambiguous, includes the city.
• NAP block above the fold. Name, full address, phone in a clearly visible block. Click-to-call on the phone. Address in a format that mirrors the GBP.
• Hours. Standard hours, plus any seasonal or holiday hours displayed clearly. Match GBP exactly.
• Embedded Google Map. Official iframe with the lat/long matching the GBP. Lazy-loaded for performance.
• Services list. The specific services offered at this location. If services differ between locations, this is where the differentiation lives.
• Local content. 300+ words of genuinely local content — neighborhood description, parking, transit, area-specific notes. Not templated.
• Photos of the actual location. Exterior, interior, key staff or operations. Same photos can be reused on the GBP for consistency.
• Reviews / testimonials from this location. A subset of GBP reviews, schema-marked. Pulls in dynamically when possible to keep recency.
• Local FAQ. 4–8 location-specific questions ("Do you offer parking?", "Are you accessible by transit?", "What ZIP codes do you serve?"). Schema-marked.
• CTA. Book, call, get directions, or contact — whatever the dominant action is for that business type. Repeated on mobile in a sticky footer.

The schema stack

Schema isn't a checkbox. It's the structured-data layer that lets search engines and AI engines parse your page without inferring from layout. The stack for a local business page:

• LocalBusiness (or the most specific subtype — Restaurant, MedicalBusiness, ProfessionalService, AutomotiveBusiness, etc.). The root entity for the location.
• PostalAddress nested in the LocalBusiness — streetAddress, addressLocality, addressRegion, postalCode, addressCountry.
• GeoCoordinates — latitude and longitude. Required for the precision signal.
• openingHoursSpecification — array of day-of-week + opens + closes. Match the GBP and the visible page hours.
• sameAs — array of URLs pointing to the GBP listing, Yelp, Apple Maps, Facebook, industry directories. Cements the entity as a single canonical record across the citation graph.
• Service — one Service entity per service offered. Include name, description, areaServed.
• AggregateRating — if reviews are published on the page (not just linked), include the aggregate. Must reflect actually-published-on-page reviews, not the GBP aggregate.
• FAQPage — covering the location FAQs.
• BreadcrumbList — the navigation path to the page.

NAP placement on the page

NAP belongs in three places on the location page, by design:

• Above the fold in a clearly-formatted block — visible immediately, click-to-call on the phone.
• In the footer — repeated for users on long pages and for crawlers parsing common page elements.
• In the LocalBusiness schema — machine-readable, exact match to the visible NAP.

Avoid putting NAP only in an image or only inside JavaScript that renders client-side. Both reduce parseability. Use HTML text and let the visual treatment come from CSS.

Local content that isn't thin

The content section of a location page is where most location pages fail. Templated copy with a city-name swap looks fine to humans on first read but gets flagged algorithmically because the same text appears on multiple URLs. The content that holds up:

• Neighborhood description. Not "we're in [city]", but "we're on [street] between [landmark A] and [landmark B], one block from [transit stop]". Specific is hard to template.
• Parking and access notes. Where to park, fee structures, accessibility. Hyper-specific, hyper-useful, naturally distinct per location.
• Local team or operations. Who runs this location, when they joined, what makes their approach distinct. Personal content earns trust and earns differentiation.
• Service-area variations. Which services are offered at this location vs others. Multi-location businesses use this for natural per-page distinction.
• Local press mentions or community involvement. Sponsorships, partnerships, charity work specific to this region. Builds the prominence signal as a bonus.

Embedded maps and directions

The Google Maps iframe is the standard embed for a reason — it ties the page to the same map index the GBP lives in and uses Google's directions engine for the click-through. Best practices:

• Lazy-load the iframe. Use loading="lazy" at minimum; for stricter performance budgets, render the iframe only after a user click or scroll.
• Embed by place ID. Use the GBP's place ID rather than coordinates so the iframe shows the verified business pin, not a generic location marker.
• Provide a "Get Directions" button that opens Google Maps directly. Many users prefer the app-native experience over the embedded view.
• Don't auto-play interactivity. Maps that scroll-jack the page hurt usability and increase pogo-stick rates.

Internal linking from the location page

The location page lives in the internal-link graph — it links out, and other pages link to it. The link strategy:

• The homepage links to all location pages. Footer or header navigation, with the city name as the anchor text.
• The location page links to relevant service pages. When a service is offered at the location, link to the service page using the service name as anchor.
• Service pages link back to all locations that offer them. Closes the loop and distributes link equity.
• Blog or content articles related to the city link to the location page. A post about "best things to do in [city]" naturally links to the local outpost.

Common mistakes

• Linking the GBP to the homepage instead of the location page. The homepage doesn't have the schema, the local content, or the topical focus. Always link the GBP to the dedicated location page.
• Using the same content across location pages with city-name find-and-replace. Algorithmic suppression follows. Each page must be 60%+ unique content.
• Schema that lists services not on the visible page. A potential manual action; at minimum a credibility-erosion signal. Schema mirrors visible content.
• Phone numbers that are tracking numbers different from the GBP. Splits the entity. If call tracking is required, use Google's call tracking that displays via the GBP, not a third-party number that doesn't match.
• Hours mismatched between page, schema, and GBP. A daily occurrence in the wild, a daily ranking penalty.

The location page is the on-page foundation. The next chapter, multi-location local SEO, takes this anatomy and scales it across regions, brands, and franchise structures without losing per-location specificity.