We separate what a platform explicitly documents from what practitioners observe, what our own project shows, and what remains uncertain. That distinction matters because Local SEO is not a laboratory environment.
Search results change, competitors change, customers behave differently, platforms update their systems and several parts of a business can change at the same time. A useful methodology should make those limitations visible rather than hiding them behind confident language.
This page explains the evidence system used across Let's Buzz Media and the live McKnight's Flat Pack Assembly case study.
The four evidence labels
Google confirms
This is the highest-confidence label for a claim about Google's published rules or behaviour. It means current first-party documentation explicitly supports the statement.
The label applies only to what the source actually says. Example: if Google documents that a service-area business is a business that visits or delivers to customers and does not serve customers at its business address, that business-model definition can be presented as platform-confirmed.
It does not automatically establish an unrelated ranking claim.
Industry evidence
This label is used when independent research, testing or repeated practitioner experience provides useful evidence that Google has not formally confirmed. The quality of industry evidence varies.
We look at the sample, method, repeatability, publication date and whether other credible evidence points in the same direction. Example: a large practitioner study may identify a relationship between a feature and stronger local visibility.
That can be worth considering, but correlation in an industry dataset is not the same as Google confirming the feature as a direct ranking factor.
Our observation
This label is reserved for things we can document from our own project records. Example: if a particular McKnight's Flat Pack Assembly page begins receiving impressions for a new group of queries after it is published, that is an observation about the page and time period.
It is not automatically proof that the same content pattern will produce the same result for another business.
Not established
Use this when the evidence is too weak, too mixed or too confounded for a definite answer. Example: if several website and profile changes are made in the same period and local visibility improves, it may be impossible to isolate the contribution of one change.
The correct conclusion may be that an improvement was observed but the cause is not established.
Our source hierarchy
The source hierarchy depends partly on the question, but the default order is:
- Primary official documentation. Google Business Profile Help, Google Search documentation and other first-party platform sources for current rules, features and published explanations.
- Technical standards. Primary standards such as Schema.org when a question concerns the vocabulary itself, alongside search-engine documentation for supported search features.
- First-party research and data. Original datasets, surveys or experiments where the methodology is visible enough to evaluate.
- Reputable practitioner research. Independent testing and analysis, especially where the platform does not publish the answer.
- Our documented observations. First-hand project evidence, useful for showing implementation and outcomes in a specific business.
- Anecdote. Useful for generating questions or identifying possible patterns, but the lowest-confidence basis for a general claim.
We prefer the original source over a summary of it whenever the original is practical to use.
How we research a Local SEO question
A consistent process reduces the temptation to start with the answer we expect.
1. Define the exact question
"Do reviews matter?" is too broad. A better question might be: "What does Google explicitly say about reviews and local ranking?" or "What happened to visibility in the case study during a period in which review activity changed?" The more precise the question, the easier it is to choose the right evidence.
2. Check primary documentation first
If the question is about a Google rule, feature, eligibility condition or published ranking explanation, we check Google's current documentation first. The date matters.
A correct answer from several years ago may be wrong after a platform change.
3. Identify what the platform does not disclose
Official documentation often answers part of a question without answering all of it. We separate the documented part from the unknown part.
We do not use a general statement from Google as permission to fill the gaps with certainty.
4. Review high-quality independent evidence
Where the platform does not publish the answer, we look for credible industry research or testing. We consider:
- what was actually measured;
- sample size and selection;
- whether the method is described;
- whether the result can be replicated or compared with other evidence;
- whether the research confuses correlation with causation;
- whether the data is still current enough to be useful.
5. Compare with our own data where relevant
If the live case study touches the same question, we compare the external evidence with what the project actually shows. Our data does not overrule a platform's published policy.
It provides first-hand context and can reveal where a practical implementation is more complicated than a tidy theoretical example.
6. State the conclusion at the right confidence level
The final wording should match the evidence. "Google confirms" should be reserved for things Google actually confirms.
"Industry evidence suggests" is different. "We observed" is different again.
And sometimes the correct ending is "not established".
How the live case study works
The principal live project is McKnight's Flat Pack Assembly, a genuine service-area business based in Ballyclare, Northern Ireland. The project is observational and longitudinal.
It is not a controlled laboratory experiment.
Establish the starting state
A useful case study needs a baseline. We record what can be established about the website, Google Business Profile, published pages, reviews, visibility and measurement setup at the start of the formal record.
For McKnight's Flat Pack Assembly, some SEO implementation was already completed before the Let's Buzz Media case-study record was formalised. That means the project must distinguish between:
- work known to have been implemented earlier; and
- changes that can be measured from a defined baseline onwards.
We will not create a fictional "before" state simply because a cleaner chart would be easier to present.
Record changes and dates
Material changes should be dated or grouped into dated stages. Examples include:
- new service or geographic pages;
- material homepage or architecture changes;
- significant Google Business Profile changes;
- new measurement setup;
- meaningful review-process changes;
- technical changes that could affect indexing or tracking.
Dates allow later observations to be interpreted in context.
Use real business outcomes where possible
Search impressions and rankings are useful, but the purpose of a local business is not to collect screenshots of search positions. Where records are reliable, the project should move through the measurement hierarchy from visibility to engagement, leads and genuine customer outcomes.
Preserve historical stages
The project record should not be rewritten after success or failure so that earlier uncertainty disappears. If an idea looked reasonable at the time but later proved ineffective, the original decision and the later result are both useful.
Read the case-study hub for how the programme is presented publicly.
Testing one change in a real business
When a specific change is suitable for closer observation, we use the following structure.
State the hypothesis
What do we think might happen, and why? The hypothesis is not a conclusion.
It is a testable expectation.
Record the baseline
Before the change, record the relevant state using repeatable settings where possible. That could be a query set, page metrics, geo-grid scan, enquiry log or another measurement suited to the question.
Define the intervention
Record exactly what changed. "Improved SEO" is not useful.
A record such as "published a dedicated service-area page and added contextual internal links from the relevant service page" is much more useful.
Record other material changes
A live business rarely changes only one thing. If a review arrives, a competitor changes, the homepage is rewritten or the Google Business Profile is updated during the same period, those events belong in the record.
Choose the measurement window and data sources
The time window should suit the question and should be chosen before interpreting the result where practical. The data source also matters.
Search Console, Business Profile performance, analytics, geo-grid tracking and enquiry records answer different questions.
Observe the result
Record what changed, including no meaningful change.
Avoid overclaiming causation
An observation can be useful without proving a direct cause. The wording should reflect that distinction.
Correlation is not causation
This is one of the most important rules on the site. Consider a hypothetical review-and-ranking example.
A business receives several new reviews during a month. Its local visibility also improves.
During the same month, the website is restructured, a new service page is published and a competitor changes category. The two events - more reviews and stronger visibility - are correlated in time.
That does not establish that the reviews caused the improvement. A useful case-study statement might say:
"Local visibility improved during the same period in which review activity "The new reviews caused the increased. Website changes and competitor movement were also present, so the business to move up in Google contribution of reviews cannot be isolated." Maps."
"The page began receiving impressions for additional queries after publication. "Publishing this page type will make This is consistent with the page becoming eligible for more searches, but the any local business rank for more case study cannot prove a universal effect." keywords." "No clear change was visible during the measurement window." "The tactic does not work." This standard protects the project from turning every coincidence into a ranking-factor claim.
Measurement hierarchy
Let's Buzz Media uses four broad levels of measurement.
1. Visibility
Examples include impressions, indexed pages, search queries, ranking trends and geographic Maps visibility. Visibility tells us whether the business is being seen.
It does not tell us whether the visibility is useful.
2. Engagement
Examples include website visits, profile actions and meaningful interactions with the business's search presence. Engagement shows that people are doing something with the visibility.
3. Leads
Examples include calls, messages, quote requests and other enquiries that can be reliably recorded. Lead data is closer to the commercial purpose of Local SEO.
4. Customers and revenue
Booked jobs, customers and revenue are the strongest business outcomes when they can be tracked accurately and reported without exposing private information. A ranking can improve while enquiries do not.
Traffic can rise while the new visitors are outside the service area. That is why rankings alone are not a complete success measure.
Use the Local SEO Measurement guide for the full framework.
Geographic measurement
Local results can vary by where the searcher is located. A single manual search from one location is therefore a weak way to describe an entire service area.
Where Maps visibility is being tested, repeatable geographic measurements are preferable. A geo-grid can sample the same query from multiple points around an area and help show the shape of visibility rather than one position.
For comparable scans, settings should be kept as consistent as practical: query, grid, centre point, spacing, device/tool configuration and date record. A geo-grid is still a measurement tool, not a business outcome.
It should be interpreted alongside enquiries, website data and the operating reality of the business. Use the Geo-Grid Tracking guide for implementation detail.
Limitations of a single case study
The McKnight's Flat Pack Assembly project is deliberately real. That is a strength for practical learning and a limitation for causal proof.
One business model
It is a service-area furniture assembly business. Findings may not transfer directly to a restaurant, hotel, dentist, multi-location retailer or other business model.
One market and geography
The business is based in Ballyclare, Northern Ireland. Competition, search demand and customer behaviour can differ significantly elsewhere.
Seasonality and changing demand
Demand can change for reasons unrelated to SEO. A short increase or decline should not automatically be attributed to an implementation change.
Competitors change too
Competitors can update websites, change profiles, gain reviews, move location or leave the market. Local search is not a static test environment.
Platforms change
Google can update ranking systems, interfaces, policies and data reporting during a measurement period.
Small samples are fragile
A new local business may have relatively few enquiries or reviews early in the project. One additional job can look like a large percentage change when the base is small.
Concurrent changes are common
A commercial business cannot always pause all other work so that one SEO variable can be isolated. We will record this rather than pretending the control is stronger than it is.
Corrections, replication and future updates
Conclusions can change when better evidence becomes available. If official documentation changes, the relevant guidance should be reviewed.
If new industry research contradicts an earlier view, the evidence should be reassessed. If the case study produces a later result that changes how an earlier observation should be interpreted, the dated history should remain visible where useful.
We do not treat replication as "another person said the same thing". Stronger replication means comparable methods, repeated observations or independent datasets that support a similar conclusion.
Readers should check the date of time-sensitive sources, the evidence label used and the limitations stated around a conclusion. Publishing rules, corrections and AI-assisted writing standards are covered separately in the Editorial Policy.
For the methodology in practice, follow the live case study.