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.
| Input | Record |
|---|---|
| Business | Stable internal ID, public name and profile URL |
| Query | Exact phrase, intended service and branded/non-branded label |
| Search context | Observation date, location, device and result surface |
| Business outcome | Qualified 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 operations4. 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.
| Observed | Hypothesis | Next check |
|---|---|---|
| Strong near the office, weak farther away | Distance or competition may be a constraint | Compare the same query at consistent locations |
| Impressions rise, enquiries do not | Query mix or conversion may be weak | Segment landing pages and inspect lead suitability |
| One service underperforms | The service may be unclear or poorly connected | Review 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.
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