Small international teams rarely need another report that sits between a diagnosis and the person who can act on it. They need to know what is limiting search visibility, what should change in the repository, and how to tell whether the change helped the right audience.
That is the reason for my SEO consulting plus engineering model: one engagement connects the investigation to the implementation. The work still has separate stages, review points and ownership. It simply does not lose context at the handoff between strategy and code.
The problem is usually the handoff, not the lack of advice
SEO recommendations become expensive when they are written for a developer who was not part of the diagnosis. “Improve the technical SEO” is not an implementation brief. A useful brief names the affected URL pattern, the observed behaviour, the likely mechanism, the change to make, and the way the result will be checked.
The same applies in reverse. Code changes made without a search hypothesis can improve a Lighthouse score while leaving indexation, intent coverage or qualified demand untouched. Performance is valuable, but it is not a substitute for knowing which constraint the change is meant to remove.
What the one-person model actually combines
The model combines two professional disciplines, not two job titles. SEO diagnosis establishes the search and business context; engineering turns the chosen intervention into a safe, reviewable change.
1. Diagnose the constraint
I start with the evidence available in the site and measurement stack: crawl and indexation behaviour, templates, internal links, page intent, content coverage, structured data, performance traces and the path from organic landing to enquiry. Search Console, analytics and CRM data are useful when access and data quality make them representative; they are not treated as complete truth by default.
The output is a prioritised constraint map. Each item states what was observed, which pages or query segments are affected, how confident the diagnosis is, and what decision the evidence supports. A suspected canonical problem and a confirmed noindex directive should not be presented with the same certainty.
2. Turn findings into an implementation brief
The next artefact is deliberately close to the code. It can include a template or component to change, the intended HTML output, redirect or canonical rules, data requirements, acceptance checks, and a rollback path. For a content or information-architecture change, it also states which intent the page is meant to satisfy and what it must not claim.
This is where a small team gets leverage: the person who explains why a change matters can also explain what the change should look like in production. The brief stays understandable to a founder or marketer, while the acceptance checks are specific enough for code review.
3. Ship the smallest safe change
Implementation should be narrow enough to attribute. Typical work may include template metadata, internal-link logic, sitemap and robots rules, structured data, rendering and performance fixes, internationalisation, or content components that make evidence easier to find and maintain.
I prefer a small pull request over a large “SEO cleanup”. A small change makes the affected scope visible, reduces the chance of accidental regressions, and gives the team a useful learning loop. When several issues share one root cause, they can still be solved together—but the relationship should be documented rather than hidden in a vague batch of edits.
4. Verify the result and its limits
Verification has two layers. First, check the release itself: rendered HTML, canonicals, hreflang, redirects, structured data, crawl rules, page performance and accessibility. Second, review the relevant search and business signals after an appropriate comparison window, segmented by page type, country, device or query intent where the data supports it.
An improvement in clicks is not automatically proof that a code change caused it. Rankings, demand, seasonality, releases and tracking changes can move at the same time. The honest conclusion may be “the implementation is correct, but the observation window is too short” or “the technical issue was real, but it was not the binding constraint for qualified demand.” Those are useful outcomes because they improve the next decision.
Operating principle: every recommendation should be traceable from observation to change to verification. If the chain cannot be shown, the recommendation is a hypothesis—not a result.
Where an expert ranking-factors survey fits
An expert survey about Google ranking factors can be a useful way to understand practitioner beliefs and identify questions worth testing. It is not Google documentation, a deterministic scoring model, or evidence that a signal causes rankings to change. Survey answers describe perceived importance; they do not replace analysis of a specific site, query set and market.
I use that kind of research as a source of hypotheses. For example, a widely discussed factor may justify checking a site’s internal-link structure or page experience, but the site’s own crawl data, rendered output and qualified-demand signals decide the priority. The practical question is not “which factor is number one?” It is “which observed constraint is limiting this site, and what is the smallest change that can test it?”
When this model is a good fit
This approach fits a small team with an existing site, a meaningful international or B2B offer, and enough access to review either the repository or the people responsible for it. It is especially useful when SEO recommendations have repeatedly stalled in a backlog, when a migration or redesign is approaching, or when content investment is being considered before the technical foundation is understood.
It is less suitable when the team needs a large editorial production operation, a full-time developer embedded for an extended product roadmap, or a specific position in Google. Search systems are probabilistic and competitive; responsible consulting can improve the quality of decisions and implementations, but it cannot promise a ranking outcome it does not control.
A practical next step
Start with one business-critical path rather than the whole site. Define the audience, the search demand, the conversion event and the code surface involved. Then produce a short diagnosis, one implementation brief and a verification plan before deciding whether more work is justified.
That is the operating model behind our SEO growth service: technical SEO, content and AI-search visibility connected to qualified demand, with recommendations your team can inspect and challenge. For the wider process—from constraint diagnosis to evidence and compounding improvements—see our Evidence Loop method.