Start with a problem you can describe
Before comparing freelancers, consultants or agencies, write down the problem the business needs to solve. “We need better SEO” does not tell a candidate whether the work concerns technical access, an unclear page, a site migration or measurement. Identify the affected pages, the visitor task and what you can currently observe. That makes an initial conversation useful without assuming that every available service is necessary.
This guide helps you brief and evaluate a project. It is not a directory, a recommendation of particular providers or an offer to employ someone. The existing provider-selection guide covers purchasing backlink placements; this guide covers a broader professional assignment with evidence, responsibilities and a handoff.
Ask for evidence that fits your situation
Google’s hiring guidance recommends investigating relevant experience, understanding proposed changes and being cautious about guaranteed first positions. Ask a candidate to explain a previous problem, their actual contribution and how the outcome was measured. Permission to share client material matters: a redacted, understandable example can be more useful than an impressive but unexplained chart.
Use a short initial brief: business purpose, affected URLs, observed issue, available evidence, access constraints, decision owner and proposed first milestone. Ask how the recommendation relates to Search Essentials, what remains uncertain and what the candidate would inspect first. A third-party audit score is an input to investigate, not proof that every suggested change is correct.
Worked brief: a small equipment-rental business
The fictional business in this example has three rental landing pages and one practical guide. It can count inquiries but has not established whether the available reports describe the same visitors or dates. The initial assignment is to diagnose those pages, propose a small set of changes and specify a useful measurement plan. It does not include a guaranteed traffic target or an unlimited content campaign.
One fictional proposal promises a first position and a large link quantity without naming the pages or work. Another offers a documented diagnosis, approved pilot changes and a handoff. Do not infer that the second provider will succeed merely from nicer wording: request the evidence, responsibilities and acceptance checks below. The table is an authored procurement example, not a current vendor comparison or a market-price estimate.
| Milestone | Requested deliverable | Acceptance check | Responsible party |
|---|---|---|---|
| Diagnosis | Affected URLs, evidence and prioritized questions | A reviewer can reproduce the observation | Consultant; business confirms context |
| Proposal | Bounded changes for three landing pages and one guide | Scope, exclusions and dependencies are explicit | Consultant proposes; business approves |
| Pilot implementation | Approved changes with a change log | Agreed technical/content checks pass; recovery path documented | Named implementer |
| Measurement | Definitions, sources, periods and intended inquiry action | Metrics use compatible scopes; no ranking guarantee | Analyst and business owner |
| Handoff | Files, explanations, access list and unresolved work | Business can continue or transfer the work | Consultant hands over; business reviews access |
Compare scope, ownership and acceptance
Separate the person diagnosing a problem from whoever will implement the change. If a consultant delivers recommendations but your developer must act on them, the proposal should name that dependency. If writing is included, specify which briefs, drafts and source checks are delivered. If links are proposed, record the actual publishing relationship and review the opportunity instead of accepting a quantity as proof of value.
Compare proposals using the same deliverables, exclusions, review dates and budget boundary. Ask what would change the scope and how you would approve that change. A price without its included work is hard to compare. This guide does not establish a universal hourly rate or certify the cheapest or best provider; it gives you a way to understand what a quote buys.
Keep access and the handoff under control
For an initial audit, prefer the evidence and viewing permissions needed for that task. Google’s Search Console permissions distinguish ownership, full and restricted users; full-user access is not simply another name for read-only access. Keep verified ownership with the business and grant additional access deliberately when an approved implementation actually requires it. Do not share an owner password as a substitute for assigning a role.
Use the worked CSV to discuss five milestones, then adapt the blank version to a real assignment. Before changes go live, agree who approves them, where the change log lives and how an unsuitable change can be reversed. At handoff, collect the agreed files, explanations, access inventory and outstanding questions. Remove access that is no longer needed through the relevant service’s controls; the sheet itself grants or revokes nothing.
Download the worked project brief · Download a blank project brief
Distinguish delivery from later business results
Accept a diagnosis when its observations and recommendations are reproducible, not when it fills a large document. Accept implementation against the agreed checks, and report subsequent business observations separately. Dates, seasonality, other changes and measurement limits may affect those observations. No one should rewrite an earlier promise after seeing the results.
A small, well-defined initial assignment can reveal whether collaboration is useful before a larger commitment. This guide does not verify industry specialists, city-specific availability, professional certifications, job candidates or named-platform expertise. Those require additional checks relevant to your case. Preserve the original brief and final handoff so a new colleague can understand what was requested, approved, delivered and still uncertain.