On-Site Local SEO: LocalBusiness Schema and City Pages

The Google Business Profile is the centre of local SEO, but it has a ceiling. The local pack holds three slots, and those three change as the searcher moves. The organic block below it holds ten results, and getting into that block is your website's job, not your profile's.

The site has a second, less visible job too: corroborating what the profile says. If the address, phone number and name appear differently on your site, you are sending Google contradictory signals. This article gathers all the on-site work in one place — from NAP consistency to LocalBusiness markup and building city pages without walking into a spam policy.

The website's three jobs in local SEO

First — appearing in the organic block. For "dentist in Baku" the local pack gives three slots; the organic results beneath give ten. Even if you miss the pack, a well-built service page can hold a place there. And the ideal state is appearing in both at once.

Second — feeding prominence. Google's notion of prominence takes your overall footprint on the web into account: links to your site, mentions in the press and in directories. Without a site there is no centre for that footprint to accumulate around.

Third — corroborating the data. Repeating the profile's address and phone in the same form on the site is a verification signal. When they contradict, Google has to decide which is right — and it does not always decide the way you would like.

NAP consistency: name, address, phone

NAP stands for Name, Address, Phone. The principle is simple: those three pieces of information should be written identically everywhere you exist — the website, the Business Profile, social media, directories, invoices.

"Identically" is meant literally. The variants below look the same to a person and different to a system:

Practical rules:

1. Pick one standard and write it down. The "official spelling" of name, address and phone should be a document for the team.
2. Take the profile's version as the master. The site adapts to the profile, not the other way round.
3. Write the phone in international format (+994…) and expose it as a tel: link so mobile users can call with one tap.
4. Put the address in text, not inside an image. Google cannot read an address in a picture and users cannot copy it.
5. Repeat it in the footer so it appears on every page.
6. Update old addresses. If you moved, stale entries in directories are the hardest thing to clean and keep contradicting you for a long time.

For service-area businesses the address is hidden, so the "A" of NAP is not shown on the site. There, name + phone + service area are kept stable by the same logic.

The contact page

The contact page usually gets the least effort on a website and is the most important page in local SEO. It is typically the second page a visitor from local search sees.

A complete contact page contains:

• The full address as text — street, building, floor, district, city, postcode
• A map — an embed plus a "Get directions" link
• The phone as a tel: link and email as a mailto: link
• Opening hours — identical to the profile, holidays included
• How to get there — a few sentences on public transport, parking and the entrance. This helps users and gives the page genuine local content
• Branches — a block or page for each location if you have several
• A link to the Business Profile — "Find us on Google Maps"
• A contact form — simple, few fields

One technical note: a map embed can slow the page down. Lazy-loading the map, or showing an image that loads the map on click, is the right approach — that belongs to the technical SEO side.

LocalBusiness structured data

Structured data means expressing what is on the page in a machine-readable form. The LocalBusiness type tells Google the business name, address, hours and contact details directly.

Google puts it like this: "With Local Business structured data, you can tell Google about business hours, different departments within a business, reviews (if your site captures reviews about other businesses), and more."

One expectation needs correcting up front. Google states plainly: "Google does not guarantee that features that consume structured data will show up in search results." Markup guarantees no rich result and is not a direct ranking factor. Its value is different: it makes your data unambiguous and reduces the chance of contradiction.

Only two properties are required: name and address. The rest are recommended: telephone, openingHoursSpecification, geo, url, priceRange, department, image.

A minimal but complete example for an address-based business:

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://example.az/#localbusiness",
  "name": "Dental Plus",
  "url": "https://example.az/",
  "image": "https://example.az/storage/clinic.jpg",
  "telephone": "+994125550011",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "45 Nizami Street",
    "addressLocality": "Baku",
    "postalCode": "AZ1005",
    "addressCountry": "AZ"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 40.3776,
    "longitude": 49.8920
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
      "opens": "09:00",
      "closes": "19:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "10:00",
      "closes": "16:00"
    }
  ],
  "sameAs": [
    "https://www.facebook.com/dentalplus",
    "https://www.instagram.com/dentalplus"
  ]
}

Points to watch:

• Use the most specific type. LocalBusiness is generic; subtypes exist — Dentist, Restaurant, AutoRepair, BeautySalon, LegalService. A precise type carries more information.
• Set an @id and reference it from your other markup, so all the schemas on the site converge on one entity. The logic is covered in schema markup and entity linking.
• What is in the markup must be visible on the page. Putting hours in the markup that are not shown on the page is a guideline violation.
• For service-area businesses, use areaServed instead of a street address.
• Separate markup for each branch — on its own page, with its own @id.

The review markup trap

This is the most common on-site mistake, and its consequence is specific.

Many sites put customer testimonials on the homepage and add aggregateRating markup so stars appear. It looks reasonable — and Google prohibits it directly:

"If the entity that's being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature."

So when the entity being reviewed controls the reviews about itself, that page becomes ineligible for the star feature. These are called "self-serving reviews", and they cover your own reviews collected on your own site — even when displayed through a third-party widget.

Note that the wording in Google's own LocalBusiness documentation points the same way: reviews may be marked up "if your site captures reviews about other businesses".

So what can you do?

• Do display customer testimonials on the site — they help conversion. Just don't add aggregateRating / Review markup to them.
• The place for stars is the Google Business Profile — real reviews accumulate there and appear in search from there.
• Spend your markup effort where it works: LocalBusiness, Service, FAQPage, BreadcrumbList.

City and branch pages

If you operate in several cities or districts, a dedicated page for each is the right strategy — on one condition: the page must carry real, distinct content.

Two different cases exist and should not be confused:

1. A physical branch. Every physical location deserves its own page, matching that branch's Business Profile and containing: its address, a map, phone, hours, the team, photos, "how to get there", the services offered there, and LocalBusiness markup.

2. A service area. Your office is in Baku but you also travel to Sumgait. You may build a Sumgait page — but it has to carry real information for that area: which services reach it, the lead time, whether there is a surcharge, examples of work done there, questions specific to the area.

A practical test: remove the city name from the page. If nothing specific to that area remains, the page is not real.

How many city pages are acceptable? There is no number — the criterion is quality. As many as you can write real content for. Three strong city pages beat twenty empty ones by a wide margin.

The doorway mistake

Google's spam policies name this practice and define it:

"Doorway abuse is when sites or pages are created to rank for specific, similar search queries. They lead users to intermediate pages that aren't as useful as the final destination."

Among the examples is one that applies here directly: "Having multiple domain names or pages targeted at specific regions or cities that funnel users to one page."

This is not merely considered "unhelpful" — it is a spam policy violation and can attract action.

Telling the two apart is easy:

The simplest rule: write the page for a real user. If a city page answers the question of someone in that city, it is not a doorway.

Internal linking

Local pages should not sit in isolation. A structure that works:

• Homepage → main services and the main area
• Service pages → the relevant city or branch pages
• City pages → the services offered in that area
• Contact page → all branch pages
• Blog posts → the relevant service and city pages
• Footer → NAP plus branches

Breadcrumb navigation helps here too: Home → Branches → Narimanov shows the structure to users and to Google, and can be marked up with BreadcrumbList.

Externally, close the profile ↔ site loop: the Business Profile should link to the relevant page (a branch profile to the branch page, not the homepage), and the site should link back to the profile.

Technical minimum

Most local search happens on mobile, with the user in motion. The technical minimum is therefore stricter here than on an ordinary site:

1. Mobile fit — the phone number must be tappable and the map usable with a finger
2. Speed — the page opens on the move, on a weak connection. Heavy map embeds and large images are the first casualties
3. tel: and mailto: links — a mobile user should not have to copy anything
4. Map and directions link — the "Get directions" button should open navigation directly
5. HTTPS — the minimum condition for trust
6. Local pages in the sitemap — branch and city pages must be included
7. Visible NAP — as text, in the footer of every page

Each of these sits on top of the technical fundamentals — a broken link or a wrong status code does the same damage on a local page as anywhere else.

Checklist