On-Page Local Optimisation
How to optimise your website pages for local SEO. Title tags, meta descriptions, NAP placement, LocalBusiness schema, and the signals that reinforce GBP authority.
Lesson 6: On-Page Local Optimisation
Title tags, NAP placement, and schema are the three levers on this page, and each one does a different job for a different audience — the title tag talks to a searcher scanning results, NAP talks to Google confirming your identity, schema talks to machines extracting facts directly. Get comfortable treating them as three separate tasks rather than one blended "make the page local" checkbox.
What the website is actually for, in a local SEO context
A Google Business Profile does the heavy lifting for local pack visibility. The website's job, covered across this lesson, is narrower but still essential: host a linked domain that lends authority back to the GBP, carry location-specific content that reinforces relevance signals covered in the previous lesson on local content, make entity data machine-readable through schema, and capture organic search traffic for the queries that never trigger a local pack result at all.
Writing a title tag that does local SEO work
The title tag is arguably the single most influential on-page element, because it's the clickable headline a searcher actually sees. A working formula for local SEO is [Primary service] in [City/area] | [Business name] — for example, "Dermatologist in Koramangala, Bengaluru | Sharma Skin Clinic," or "JEE Coaching in Andheri West | IIT Mentors Institute." For a location-specific page rather than a service page, flip the order slightly: "Sharma Skin Clinic — Koramangala, Bengaluru | Hours, Address & Appointments."
Keep it under 60 characters, since Google truncates anything longer in the results display. Put the local keyword near the front rather than burying it after the brand name, include the business name for recognition, and resist the temptation to stuff more than one city or service into a single title — a title trying to cover three services and two cities at once ranks for none of them particularly well. This overlaps with the keyword-mapping work from keyword research for local intent — each title tag should map to one keyword cluster, not several at once.
Meta descriptions: no ranking effect, real click-through effect
Meta descriptions don't feed the ranking algorithm directly, but they're often the deciding factor between two results with similar rank — a well-written description gets clicked, a generic one doesn't. A working formula: [Key service] in [area/city]. [Key differentiator]. [CTA with local context]. For example: "Dermatology clinic in Koramangala, Bengaluru. Board-certified dermatologists. Acne, laser & cosmetic treatments. Book your appointment online — same-week slots available." Stay under 155 characters, include the location, include a genuine differentiator rather than a generic claim, and end with a specific CTA.
NAP on the website: the exact-match rule
Every character of your website's NAP needs to match the GBP's NAP exactly — not approximately, exactly. "5th Block, Koramangala" on GBP and "5th Block Koramangala" (missing the comma) on the website is a minor inconsistency that most humans wouldn't notice, but it's the kind of small discrepancy that dilutes the reinforcement signal between the two sources rather than strengthening it. Place NAP in crawlable HTML text — never inside an image, never rendered only via JavaScript that a crawler might not execute — in the site footer for single-location businesses, on a dedicated contact page, and on each location-specific page for multi-location businesses, using that location's own address rather than a shared block. The fundamentals of why this matters at all are covered in NAP and citations 101.
LocalBusiness schema: the highest-leverage single addition
Among everything covered in this lesson, LocalBusiness JSON-LD schema does the most work per hour of implementation effort, because it turns your business identity from something Google has to infer from prose into something it reads directly from structured fields. The minimum viable implementation needs the @type (the specific business type — MedicalClinic, Restaurant, and so on), name, address as a PostalAddress object, telephone, openingHoursSpecification, and geo coordinates. Worth adding beyond the minimum: url, aggregateRating if reviews display on the page, sameAs links pointing to your Practo profile or Facebook page for entity disambiguation, priceRange, and a list of the services actually offered. Validate through Google's Rich Results Test before considering the job done — a schema block with a typo in a required field often validates as "present" while silently failing to render any rich result.
A worked example: fixing a Chennai clinic's on-page gaps
A dermatology clinic in Anna Nagar, Chennai, had a technically complete website — every service listed, every page loading fast — but was invisible for "skin clinic Anna Nagar" despite ranking reasonably for the clinic's own brand name. An audit found three specific gaps: the homepage title tag read "Welcome to [Clinic Name]" with no service or location keyword at all; the NAP in the footer used the clinic's old address from before a 2023 move, while the GBP reflected the current one; and there was no schema block anywhere on the site. Fixing all three — rewriting the title tag to "Dermatologist in Anna Nagar, Chennai | [Clinic Name]," correcting the footer address to match the current GBP exactly, and adding a MedicalClinic schema block with the correct geo coordinates — didn't require touching the clinic's actual service content at all, and organic visibility for location-modified searches improved within the following crawl cycle. The lesson: on-page local optimisation often isn't about writing more content, it's about correcting a small number of specific, mechanical elements that were quietly wrong.
The complete checklist
For each location page: title tag includes the location keyword, meta description includes a location reference and a CTA, H1 pairs service and location, NAP appears in crawlable HTML text rather than an image, NAP matches the GBP exactly, a Google Maps embed exists for that specific location, LocalBusiness schema is implemented, the GBP's website field links to this specific page rather than the homepage, and internal links connect to sibling location pages and relevant service pages.
What practitioners get wrong
The most frequent mistake is treating on-page optimisation as a one-time setup rather than something that needs re-checking after any site migration, redesign, or address change — the Chennai example above is a common pattern precisely because addresses change more often than footers get audited. A second mistake is writing schema that technically validates but describes the wrong @type — using the generic LocalBusiness type when a more specific one like MedicalClinic or Restaurant is available and more precisely matches what Google and AI systems are actually looking for. A third is over-optimising the title tag into an unreadable keyword string rather than a title a human would actually want to click, undermining the on-page keyword placement work covered in how Google ranks local businesses.
FAQ
Does adding schema markup guarantee a rich result or ranking boost? No. Schema makes your data easier for Google to read and extract; it doesn't guarantee any particular display treatment or ranking change on its own. Treat it as removing friction from how your information gets understood, not as a direct ranking lever with a predictable payoff.
Can I use the same NAP block across every page, or does each location need its own? For a single-location business, one consistent NAP block sitewide is correct. For multi-location businesses, each location page needs its own specific NAP matching that location's own GBP — using one shared NAP block across a multi-location site is itself the kind of inconsistency this lesson is warning against.
What's the fastest way to check if my current schema is working correctly? Run the page through Google's Rich Results Test and a schema.org validator — the Rich Results Test shows what Google specifically detects and any errors; a general validator catches syntax issues the Rich Results Test sometimes doesn't flag. See structured data and schema for the full walkthrough.
Does the meta description need to be different for every location page? Yes, for the same reason unique location content matters — a meta description copied across every location page with only the city swapped signals the same thin-content pattern that duplicated location content does, even though meta descriptions themselves aren't a direct ranking factor.
Next lesson: Reputation across directories →
A score you can argue with, not a black box
Rank OS gives every profile a 0–100 score built from five weighted dimensions — Relevance, Review Health, Freshness, Entity Authority and AIO Readiness — and the weights are tunable. Underneath it sits a ranked list of the fixes that move the number, each with the point lift it unlocks.
Ready to have this run for you?
Book a free audit — we'll show you where you stand in 48 hours.