When a site already has location pages and performance is uneven, the first question is not which city keyword is missing. It is which pages deserve to stay indexed. A useful audit separates pages that prove a real local offer from pages that only change the place name.
First 5 checks
Use this priority order before rewriting copy or creating another city page.
- Index eligibility: The URL returns HTTP
200, is not blocked, has indexable content, and points to the canonical page you want in Search.[1] - Business reality: The page matches a real storefront, office, or service area customers can verify in the business’s public details.[2]
- Local evidence: The page shows service availability, local proof, staff or access details, or examples from that market instead of reused city-name copy.
- Consistency: The name, address or service area, phone, hours, categories, and schema agree with the footer, contact page, Google Business Profile, and the page itself.
- Action path: A visitor can call, book, request a quote, get directions, or submit a form without hunting, and the business can measure that action.
In real audits, the most common failure pattern is a set of cloned city pages that all rank poorly while one service-area hub with better proof earns more calls. The fastest improvements usually come from fixing mismatched business details, pruning pages with no evidence, and moving phone or form actions higher on the page before adding new copy.
Google’s baseline is still the floor: Googlebot must be able to fetch the page, the URL should return HTTP 200, and indexable content must be present.[1] After that, judge the page as a customer would. Does it provide original local details, substantial service information, and evidence that the business knows this market?[3]
Check local specificity
This is where weak city pages usually separate themselves from useful location pages.
A useful location page answers local buying questions that a generic service page cannot answer. For a storefront, that usually means the exact address, hours, local phone number, parking or access notes, team or department details, service availability, and proof from that location. For a service-area business, it means the cities or postal codes actually served, the services available there, travel limits, booking rules, and proof that the business has done work in that area.
Use Google Business Profile guidelines as a reality check.[2] Google tells businesses to represent the business as it is known in the real world, keep the address or service area accurate, choose the fewest categories needed, and avoid more than one profile per business location. The same guidance also says the website and phone should represent the individual business location, and that a local phone number is preferred over a central call center number when possible.
Service-area pages need an extra check because fake local presence is common. Google’s service-area guidance says a service-area business can set up to 20 service areas, and the overall area generally should not be more than about 2 hours of driving time from where the business is based.[4] Businesses often misread that as permission to build a page for every town inside the radius. It is better treated as a coverage guardrail, not proof that every city deserves its own URL.
If a plumbing company has one staffed base and lists 60 city pages with no job photos, no service differences, no local scheduling detail, and no local proof, those pages are not local evidence. They are a rewrite or merge queue.
| Local element | Pass condition | Fix if it fails |
|---|---|---|
| Address or service area | The visible page matches the real storefront address or the actual cities, ZIP codes, or neighborhoods served. | Remove fake office language, hide a home address when the business does not receive customers there, or merge thin city pages into a real service-area page. |
| Services by location | The page lists only services available in that area, such as same-day repair, showroom visits, delivery, emergency work, or appointment-only service. | Delete services that the location cannot provide, then add booking limits, coverage notes, or local availability rules. |
| Local proof | The page includes location-specific reviews, photos, case notes, staff details, or project examples the business has the right to publish. | Add real proof before expanding the page; if no proof exists, merge the URL with a stronger parent service page. |
| Structured data | LocalBusiness structured data[5] and the visible business details agree. | Use the most specific real business subtype and remove markup for locations that do not exist as real branches or service areas. |
| Contact path | The page has a local call, form, booking, or directions path that matches the user’s intent. | Move the primary action near the top of the page and track the action as a measurable event. |
Do not count a city name in the title as local specificity. A better test is this: remove the city name from the page and ask whether a customer could still tell which location the page is for. If the answer is no, the page needs local proof, not more keywords.
Review consistency and structure
Once the page has a real reason to exist, check whether it can be crawled, indexed, measured, and used.
In Google Search Console, inspect a sample of location URLs and confirm that the canonical URL, indexability, and live page status match the page you want in Search.[6] If the URL returns a soft error, points to a different canonical page, or is blocked by robots.txt, rewriting copy will not solve the first problem.
For technical cleanup, keep the rules simple. A live location page should return HTTP 200; a permanently moved location page should use a permanent redirect such as 301 or 308, which Google documents as signals that the redirect target should be canonical.[7] In audits, old city URLs often pass through a WordPress plugin, a CDN rule, and an HTTP-to-HTTPS redirect before loading. Resolve those chains before judging the content.
Sitemaps should also stay boring. For most small business sites, the issue is not sitemap capacity; it is leaving old, redirected, duplicate, or noindex location URLs in the sitemap after a redesign.
- Unique local copy: Replace "We serve Plano" with the services available there, the booking window, and a real example such as "water heater replacement appointments are offered in Plano on weekdays, with emergency calls routed through the main service line."
- Consistent NAP details: Match the visible name, address or service area, phone, and hours against Google Business Profile, footer text, contact pages, and any location schema.
- Relevant services by location: If only one office handles commercial work, do not list commercial service on every city page.
- Internal links from nearby pages: Link from the main service page, service-area hub, staff page, or nearby location page using descriptive anchor text such as "AC repair in Mesa," not "click here."
- Local testimonials, photos, or case examples: Use proof tied to the location, service, or staff member; a generic five-star quote copied across 30 pages is not local proof.
Performance and accessibility belong in the first pass because location pages are often the first page a mobile visitor sees. PageSpeed Insights reports both field data from the Chrome User Experience Report and lab diagnostics from Lighthouse.[8] The Core Web Vitals "good" thresholds are LCP at or below 2,500 ms, INP at or below 200 ms, and CLS at or below 0.1 at the 75th percentile.[9]
Accessibility checks should focus on tasks, not only scores. WCAG 2.2 includes conformance levels A, AA, and AAA, and its contrast success criterion 1.4.3 requires normal text to have a contrast ratio of at least 4.5:1, with large text at least 3:1.[10] On a location page, that means phone links, form labels, map controls, review sliders, and "get directions" buttons must remain usable by keyboard and readable on mobile.
Use a small workflow before editing copy. If you use Website Advisor, treat it as a triage layer: it can collect page-level issues in one place, then you still confirm crawl and index status in Search Console, performance in PageSpeed Insights, and business details in Google Business Profile.
| Step | What to record | Decision rule |
|---|---|---|
| 1. Export location URLs | All location pages from the CMS, XML sitemap, and Search Console. | If a URL is not meant to rank or convert, remove it from the audit set and document the redirect, noindex, or merge plan. |
| 2. Check index eligibility | Status code, indexability, canonical URL, robots.txt access, and sitemap inclusion. | Fix blocked, non-200, or wrong-canonical URLs before rewriting content. |
| 3. Score local evidence | Address or service area, local service details, local proof, staff or access notes, and a clear contact path. | Keep pages with 4 or 5 evidence points; rewrite pages with 2 or 3; merge pages with 0 or 1. |
| 4. Compare business data | Name, address, phone, hours, categories, service areas, and services against Google Business Profile. | Any mismatch that could confuse a customer becomes a same-day fix. |
| 5. Check page experience | Mobile Core Web Vitals, Lighthouse accessibility issues, visible form errors, and click-to-call behavior. | Fix failures that block calls, forms, directions, or readable content before adding new location pages. |
| 6. Check measurement | Phone clicks, form submissions, booking clicks, and direction clicks in analytics. | Mark important actions as key events in Google Analytics 4[11] so location-page decisions use conversions, not only sessions. |
Here is a simple worked example. A roofing company audits 12 location pages. Before the audit, 8 pages use copied service text, 3 pages show hours that do not match Google Business Profile, 2 pages redirect through more than one old URL before loading, and 0 pages track form submissions as key events. After cleanup, the team keeps 5 pages with real local proof, rewrites 4 pages with photos and service-area notes, redirects 3 thin pages to a stronger service-area hub, fixes the hour mismatches, and tracks call clicks and form submissions. That is a better outcome than publishing 12 longer pages with the same weak local signal.
Avoid doorway-style pages
This is the risk check before you approve a large batch of location URLs.
Google’s spam policies define doorway abuse as pages created to rank for specific, similar queries that lead users to intermediate pages that are not as useful as the final destination.[12] The examples include pages targeted at specific regions or cities that funnel users to one page, and substantially similar pages that sit closer to search results than to a clear site hierarchy.
Use this decision rule tomorrow: keep a location page indexable only when it has a business reason to exist outside Search. That reason might be a staffed location, a defined service area, a different service mix, a local team, different hours, unique access details, or proof from work in that area. If the page only swaps "Austin" for "Round Rock," merge it into the best matching hub page or redirect it to the nearest useful page.
Doorway risk rises when a site creates pages faster than it can add evidence. If the business has 6 real service areas and 40 city pages, build the 6 strongest pages first. Add more only when you can support each page with service details, customer questions, local proof, and a measurable contact path.
Review notes
Last reviewed: April 23, 2026. Core Web Vitals thresholds, structured-data expectations, Google Business Profile policies, spam policies, and WCAG guidance can change; use the Sources section to verify date-sensitive details before acting on audit results.
The final audit call is simple: keep pages that pass the first 5 checks, improve pages with fixable evidence gaps, and merge or redirect pages that exist only for city coverage. That gives the site a smaller set of location pages that customers can trust and the business can actually maintain.
Sources
- Google Search technical requirements: https://developers.google.com/search/docs/essentials/technical
- Google Business Profile guidelines: https://support.google.com/business/answer/3038177?hl=en
- Google guidance on helpful, reliable, people-first content: https://developers.google.com/search/docs/fundamentals/creating-helpful-content
- Google service-area business guidance: https://support.google.com/business/answer/9157481?hl=en
- Google Local Business structured data: https://developers.google.com/search/docs/appearance/structured-data/local-business
- Google Search Console overview: https://search.google.com/search-console/about
- Google redirect guidance: https://developers.google.com/search/docs/crawling-indexing/301-redirects
- PageSpeed Insights documentation: https://developers.google.com/speed/docs/insights/v5/about
- web.dev Core Web Vitals thresholds: https://web.dev/articles/defining-core-web-vitals-thresholds?hl=en
- W3C WCAG 2.2: https://www.w3.org/TR/WCAG22/
- Google Analytics 4 key events: https://support.google.com/analytics/answer/13128484?hl=en
- Google Search spam policies: https://developers.google.com/search/docs/essentials/spam-policies