Quick answer
Good SEO onboarding produces three things before any promise of results: minimal, revocable access, a dated baseline whose limits are known, then a 90 day plan ordered by impact, confidence, effort, and risk. The 90 days frame the work; they guarantee no indexing, no ranking, and no traffic. The client should know what will be observed, decided, delivered, and re-checked at each stage.
Key takeaways
- Don't start the audit until the objective, the conversions, the access, and the owners are verified.
- Separate the observed problem, the assumed cause, the recommendation, the applied change, and the measured result.
- Grant least privilege: administrator access "just in case" is a security debt.
- A useful audit ends with a decision queue, not a 150 slide presentation.
- The 90 day plan has exit criteria; it isn't a decorative calendar.
Operating definition of onboarding
SEO onboarding is the controlled period during which the agency turns the commercial context into a verifiable working system. It covers knowledge transfer, authorizations, measurement, diagnosis, prioritization, and the rules of collaboration.
An audit is only one component of that period. With no baseline, technical owner, or conversion definition, the audit can identify hundreds of gaps without enabling a single safe decision.
The model rests on five registers:
- Access: who can read, modify, publish, or delegate?
- Measurement: which metrics, dimensions, windows, and exclusions?
- Initial state: what do we know as of the start date?
- Hypotheses: why should an action change a result?
- Decisions: who accepts the risk and approves execution?
The minimum access matrix
Exact roles vary by platform. Always check their current documentation. The matrix below is a starting point, not an automatic authorization.
| System | Usual need during the audit | Recommended initial level | Possible temporary elevation | Proof of revocation |
|---|---|---|---|---|
| Google Search Console | Read performance, indexing, and properties | Read access where sufficient | Full access for certain approved configurations | Export of the user register |
| Google Analytics | Read events and conversions | A suitable read or analyst role | Editor only for an approved measurement plan | Screenshot of the role after closing |
| CMS | Examine templates, metadata, and content | Staging or read-only account | Publishing limited to a scope | CMS log and deactivation |
| Tag manager | Audit firing | Read | Publishing by the client owner | Version history |
| Server/CDN logs | Diagnose bots and errors | A minimized, bounded extract | Justified temporary access | Closure ticket |
| Code repository | Read rendering and configuration | Read on the required repository | Branch and pull request, never a shared secret | Deletion of the key or account |
Google documents Search Console user and permission management as well as the Analytics Admin API. These pages describe Google's mechanisms; they don't prove that your own governance procedure is correct.
Full 90 day procedure
Days 0 to 5: frame before collecting
- Restate the objective as an observable outcome: for example qualified requests from unbranded pages, not "be better on Google."
- Define the scope: countries, languages, subdomains, products, CMS, teams, and exclusions.
- Name an owner for business, technical, content, data, and approval.
- Write down the already known risks: a planned migration, seasonality, consent, technical debt, a media campaign, or a redesign.
- Record the exact commercial promises so any ambiguity can be corrected immediately.
Exit criterion: objective, scope, RACI, and restrictions approved in writing.
Days 3 to 10: open and test the access
Request only the roles you need. Test each access with a real read action; an invitation sent isn't functional access. Never copy a personal password into a shared document. For each authorization, record the owner, the justification, the grant date, and the review date.
Exit criterion: 100% of the necessary sources are accessible or logged as blocking dependencies with an owner.
Days 5 to 15: freeze the baseline
Export the data before any major change. Document: date range, time zone, search type, filters, attribution model, consent status, conversion definitions, and any sampling.
Google explains that Search Console groups and filters its data by report and that average position isn't equivalent to a universal ranking. The baseline must therefore be reproducible, not simply captured in an image.
Exit criterion: another person can rebuild the starting KPIs with the same filters.
Days 10 to 25: audit by decision chains
Don't launch every available crawl "to be thorough." Follow the journey: discovery → crawl → rendering → indexing → selection → click → behavior → conversion. For each problem:
- state the affected URL or group;
- keep the raw evidence;
- distinguish symptom from assumed cause;
- estimate the possible impact and the confidence level;
- name the validation test;
- define the rollback procedure.
Google describes the general behavior in three stages (crawling, indexing, and serving) while specifying that a page meeting the requirements isn't guaranteed to be crawled, indexed, or displayed.
Exit criterion: critical problems are reproducible and mere tool warnings are separated from real incidents.
Days 20 to 30: build the prioritized queue
Give each action a score for impact, confidence, effort, and risk. Add a category: correction, learning, growth, or maintenance. Then impose a work in progress limit.
A very "profitable" but irreversible priority doesn't automatically jump ahead of a security fix. The score supports judgment; it doesn't replace it.
Exit criterion: the client approves the first cycle's three to five decisions and the explicitly deferred actions.
Days 31 to 60: run the first controlled cycle
Work in batches small enough to isolate a regression. Before publishing, check rendering, links, canonicals, visible structured data, conversion tracking, and consistency with the content. After publishing, check the HTTP status, the produced HTML, the events, and the logs.
Exit criterion: every change has a ticket, a validation, a publication date, a checked sample, and a review date.
Days 61 to 80: observe without telling a premature causal story
Compare against the baseline using the defined window. Also look for competing explanations: season, campaign, brand change, Google update, redesign, or market event. A rise after publishing isn't automatically caused by the publishing.
Exit criterion: every finding is labeled "observation," "probable association," "inconclusive test," or "incident."
Days 81 to 90: hold the review and renew the plan
Present the decisions, deliverables, evidence, gaps, learnings, and risks. Close unnecessary access. Turn the remaining questions into the next cycle's hypotheses. The final deliverable isn't "the audit is finished," but a client system that can actually be operated.
Exit criterion: next plan approved, dependencies reassigned, access reviewed, and the hypothesis register updated.
Minimum RACI
RACI means responsible for execution, accountable approver, consulted, and informed. One person can hold several roles in a small organization, but the approver of a risky change must stay explicit.
| Decision | Agency | Client marketing owner | Client technical | Legal / data |
|---|---|---|---|---|
| Conversion definitions | Consulted | Approver | Consulted | Consulted if personal data |
| SEO priority | Responsible | Approver | Consulted | Informed |
| Template change | Recommends/checks | Informed | Responsible and approver | Consulted if compliance impact |
| Editorial publishing | Produces or advises | Approver | Informed | Consulted depending on sector |
| Measurement incident | Diagnoses | Informed | Shared responsibility | Consulted |
| Access revocation | Confirms | Approver | Responsible | Informed |
Worked example: a SaaS that "isn't recovering"
A fictional example. A B2B SaaS arrives reporting a 35% drop in organic traffic over two months. That figure comes from an Analytics chart, with no annotation. The agency could promise a recovery; it chooses first to reconstruct the state of things.
The baseline reveals three elements: consent changed midway through the period, a brand campaign was stopped, and the /resources/ directory genuinely generates fewer impressions in Search Console. The HTML audit also shows that a new JavaScript rendering sometimes omits the navigation links from the initial response.
The plan therefore distinguishes:
- measurement: reconcile the session event with the consent period;
- demand: separate branded and unbranded queries;
- technical: reproduce the rendering with no JavaScript, fix the component, test a batch of pages;
- content: don't rewrite 200 pages before checking indexing and intent.
By day 60, the links are present and the tracking is documented. Unbranded impressions stabilize, but no isolated causal link is asserted. The useful outcome of the first cycle is a corrected measurement system, a closed technical incident, and a better targeted content hypothesis.
What the data proves and doesn't prove
On Reddit, people ask why a site still gets no traffic after reindexing or how to handle the inspection tool's limits. These are qualitative demand signals. The dates, profiles, and cases don't constitute a representative sample.
Common mistakes and stopping conditions
- Requesting all administrator access: stop and go back to least privilege.
- Auditing with no defined conversion: the technical list can't be tied to a business priority.
- Comparing non-comparable periods: annotate season, consent, media, and migrations before concluding.
- Applying hundreds of fixes in one batch: reduce the sample and prepare the rollback.
- Presenting a crawler's scores as impacts: reproduce the problem in the rendering or the real data.
- Promising a recovery by day 90: replace the promise with controllable delivery and observation criteria.
- Leaving access open after the cycle: the access review is a mandatory deliverable.
Reusable asset: the 90 day exit sheet
For each phase, record: required input, owner, evidence, date, status, blocker, decision, and exit criterion. Add a hypothesis register with this structure:
If we apply [change] to [URL population], then [metric] should move within [window], because [assumed mechanism]. We will stop or revise if [signal], and we will control for [competing explanations].
Measure onboarding quality with:
Traceability rate = decisions holding evidence, an owner, and a date ÷ total decisions.
The goal is 100% traceability on critical decisions, not an artificial score applied to every conversation.
How SEOryon fits in
Based on its verified public functions, SEOryon can analyze SERPs and questions, propose content recommendations, apply a brand voice, check cannibalization, read Search Console and Analytics data in read-only mode, track mentions or citations across several AI assistants, and publish to several CMSs. Its free score examines 27 signals on a URL.
These functions can reduce collection work and some repetitive tasks. They don't validate access, don't define the conversion, don't prove a cause, and don't replace the client's approval. Use semi-autopilot mode until the process, the rights, and the controls are stable.
Measurable exercise
Simulate onboarding a client on a test property. Deliver: an access matrix, a reproducible baseline, a RACI, ten classified findings, five decisions, and a 30/60/90 day plan. The exercise succeeds if a second person can:
- rebuild three KPIs without asking you for the filters;
- reproduce the three priority problems;
- identify the approver of each change;
- tell every observation apart from the hypotheses;
- check that every access has a review date.
Recommended path
- Return to the full system for running an SEO agency.
- Turn the baseline into ROI reporting and a QBR.
- Check roles, tokens, and revocations with the guide to white label data security.
- Align the plan's milestones with the method for reducing churn and managing expectations.
FAQ
What should an SEO agency ask for during onboarding?
Objectives, conversions, scope, change history, owners, minimum access, restrictions, and decisions already made. Ask for the data you need, not every company secret.
Must an SEO audit precede any action?
A proportionate diagnosis must precede a risky action. An obvious incident may require a fast fix, but keep the evidence, an approver, a test, and a way to roll back.
Can you promise SEO results in 90 days?
Not responsibly. You can promise deliverables, controls, and decision timelines subject to dependencies. Crawling, indexing, and ranking aren't fully controllable by the agency.
Why do Search Console and a rank tracker differ?
They don't observe the same thing: aggregation methods, location, device, query, personalization, and window can all vary. Document each method before comparing.
Should you give the provider administrator access?
Only when a specific action requires it, with approval, a limited duration, a log, and revocation. Start with the least privileged role capable of doing the task.
References
- How Google Search works (Google Search Central)- SEO Starter Guide (Google Search Central)- Set up and use Search Console
- Manage Search Console users and permissions
- Google Analytics Admin API
- Using Search Console and Analytics together
- Creating helpful, reliable, people-first content
- Reddit: site reindexed but still no organic traffic
Method and update note
The calendar is an operating framework, not a universal estimate of results. The examples and thresholds are illustrative. Reviewed 16 July 2026, translated and edited 22 July 2026. Revisit this guide when Google's roles, Search Console reports, SEOryon's public functions, or security obligations change.