1. Define the question before collecting data

This guide is a diagnostic process for a genuine local business. It does not reverse-engineer Google’s ranking algorithm. The output is a prioritised investigation log, not a guaranteed ranking plan.

Write down the service, location and customer action you care about. “Improve local SEO” is too broad. “Increase suitable enquiries for residential extension design within our service area” gives the analysis a useful boundary.

InputRecord
BusinessStable internal ID, public name and profile URL
QueryExact phrase, intended service and branded/non-branded label
Search contextObservation date, location, device and result surface
Business outcomeQualified enquiry definition and current capacity

2. Separate the ranking dimensions

Google describes local results using relevance, distance and prominence. These are categories for diagnosis, not a published scoring formula. You cannot calculate a guaranteed local position by adding three scores.

Our working checklist translates those categories into questions. Does the profile accurately describe the service? Does the business genuinely operate where the searcher needs it? Is there consistent evidence of the business across its site and public records?

  • Check the primary category against the actual core activity.
  • Compare searches near the business with searches near the edge of its service area.
  • Check whether results change between Maps, the local pack and ordinary organic listings.
  • Treat a competitor comparison as a hypothesis source, not proof that one feature caused a ranking.

3. Audit identity before producing more content

Create a single record of the approved business name, location, phone, website and service area. Compare that record with visible website content, business profile data and relevant directories.

Do not “fix” legitimate differences blindly. A legal trading name can differ from a registered company name. A service-area business may keep its private address unpublished. Document the reason for a difference and resolve actual ambiguity.

business_id: pressine-internal-001
public_name: Example Studio
website: https://example.com/
profile_url: <verified profile URL>
service_area_source: owner-approved coverage list
reviewed_at: 2026-09-23
owner: business operations

4. Follow the website path

Open the relevant result as a customer. Confirm that it leads to the right service, that the page explains eligibility and coverage, and that the next step works on a phone. A visibility problem and an enquiry problem may exist at the same time.

Then inspect the technical path: response status, crawl permission, canonical, internal links and rendered content. A page can look correct in a browser while serving a redirect loop or an unintended canonical to crawlers.

  • The service URL returns 200 and is not blocked unintentionally.
  • The canonical identifies the intended page, not the homepage by default.
  • The first HTML response contains the main service information.
  • The enquiry route identifies success and failure honestly.

5. Keep a reproducible observation log

Collect observations with the same method over time. A change in measurement location can look like a ranking change. Branded demand can make aggregate clicks rise even when non-branded service visibility is flat.

Separate observations from explanations. “Calls fell” is an observation. “The new title caused calls to fall” is an explanation that needs evidence and alternative causes considered.

ObservedHypothesisNext check
Strong near the office, weak farther awayDistance or competition may be a constraintCompare the same query at consistent locations
Impressions rise, enquiries do notQuery mix or conversion may be weakSegment landing pages and inspect lead suitability
One service underperformsThe service may be unclear or poorly connectedReview page content, profile fit and internal links

6. Prioritise changes with a verification step

Give each action a reason, an owner, an expected signal and a review date. Fix a broken contact route before rewriting ten location pages. Resolve incorrect public facts before adding more schema.

Record deployment dates and other changes, including promotions, opening hours and staffing. Compare equivalent periods where possible. A simple before-and-after comparison is directional evidence, not a controlled causal experiment.

  • Acceptance: the underlying technical or content problem is demonstrably fixed.
  • Observation: the relevant visibility or conversion signal is tracked.
  • Interpretation: seasonality, query mix and capacity are considered.
  • Next decision: keep, refine, investigate or stop.
Written by Pressine

Our studio combines design, software development and search. These guides document our approach and link to primary references where platform behaviour matters.

About our method