What should an SEO agency actually deliver?

A proposal can contain every familiar SEO service and still leave a buyer unsure what will happen next month. Audits, content, reporting and strategy are categories of work. They become a useful scope only when the document says what will be delivered, who can act on it and how both sides will judge completion. Before comparing prices, make the proposals comparable at that level.

This guide offers a practical way to prepare a brief and review an engagement. The examples describe a fictional B2B website, but the questions also work for many other organizations. Start with the business decision you need help making, then ask each agency to show how its work supports that decision.

Describe the business problem before the service list

Write down the offer that matters, the audience it serves and the pages involved. A company launching a new product needs a different engagement from one merging several old websites. “Improve organic traffic” leaves too much room for interpretation. “Help the right buyers find and understand our new inventory product” gives the agency a more useful starting point.

Include constraints. Perhaps the developer can accept only a few tickets per month, the legal team reviews every product claim or the content manager is already committed to a launch. These facts influence the order and amount of work. An agency cannot solve a capacity problem by delivering more recommendations, so make the implementation environment part of the brief.

Google's advice on hiring an SEO encourages buyers to ask about expected results, communication and measurement. Use those questions to start a concrete discussion. Ask the agency to explain one likely deliverable in enough detail that you can picture your team using it.

Separate an audit from an implementation engagement

An audit is a diagnosis. It might provide a page inventory, technical findings, content observations and a recommended sequence of changes. Its value depends partly on whether someone can act on it. Ask for a sample issue, with confidential details removed, and examine whether it identifies the affected pages, evidence, proposed action and completion check.

Implementation is a different commitment. It can mean writing developer tickets, editing pages, reviewing a staging release or directly publishing approved changes. The proposal should name which of these actions are included. If the agency only advises, say who supplies the developer and writer. If it publishes, define the approval process and the access required.

For a fictional software company, an audit might find that two product sections compete for the same reader task. Implementation could involve choosing the surviving pages, revising content, mapping redirects and checking navigation after release. A proposal that says only “content optimization” does not tell you which of those steps you are buying.

Ask for deliverables that survive the meeting

A useful issue register should remain understandable after the consultant leaves the call. Request a stable location for working documents and a consistent format. Each task should have an owner, a status and an explanation of what closes it. This is ordinary project management, but it prevents a monthly presentation from becoming the only record of the engagement.

For content, specify whether the agency delivers briefs, drafts, edited copy or published pages. Clarify who checks product accuracy and whether subject matter interviews are included. Define the number of review rounds or an equivalent review process. A beautifully written draft is not complete if no one has confirmed that it describes the product correctly.

For technical work, request a release checklist. It should identify the environment being tested, the URLs or templates affected and the person responsible for final approval. The checklist need not be elaborate. Its purpose is to keep a recommendation from disappearing between a document, a development ticket and a production release.

Agree on access and ownership

Create an account list before granting permissions. Search reporting, analytics, the content system and the code repository may have different owners. Begin with the access needed for the current stage and expand it deliberately. An early review does not automatically require the same permissions as a publishing engagement.

Your organization should know where its data lives and who can export it. Ask which accounts remain yours after the contract ends, which documents you receive and how agency access will be removed. Also ask about subcontractors if they will handle your information or change your website. These are easier conversations before work begins than during an urgent handover.

Include an emergency contact path for an accidental change or a failed release. Define who can reverse a change and where the last approved version is stored. The scope should support safe execution as well as normal delivery. A rollback procedure is especially useful when several vendors work on the same website.

Build reporting from three layers

The first layer is work completed: what changed, when it shipped and what remains blocked. The second is search observation: which relevant pages or query groups changed during the review period. The third is business context: whether the visitors performed actions your company considers valuable. Each layer answers a different question, so keep the labels clear.

Search Console's performance documentation explains metrics including clicks and impressions and the ways reports can be grouped. Those observations can help evaluate search activity. Your own qualification process is still needed to distinguish a useful inquiry from an irrelevant form submission.

Ask the agency to state the comparison period and any known disruptions. A product launch, tracking change or seasonal campaign can affect interpretation. Reporting should make those events visible. A chart with an upward line is not enough to explain why it moved, and a flat month does not by itself prove that no worthwhile work was completed.

Define what happens when priorities change

Most engagements encounter a new request. A product name changes, a migration becomes urgent or a stakeholder wants an extra article. The agreement should explain how new work is assessed and what it displaces. Otherwise, both sides can believe they are being reasonable while quietly expecting different outcomes.

Use a short planning record at each review. List the next tasks, their dependencies and the decisions needed from your team. If a task is waiting for approval, show that status plainly. This gives you a better basis for discussing delays than a general statement that progress is slow.

Compare proposals with a worked task

Give shortlisted agencies the same small scenario. For example: a product page is being retired, a related page will take its place and several campaigns still link to the old address. Ask each agency to describe its role from planning through verification. You are looking for clear responsibilities and sensible questions, not free consulting on your whole website.

Record what is included, what your team must provide and what counts as finished. An audit-only proposal may be exactly right if you have strong internal delivery capacity. A broader engagement may be useful if you need help turning decisions into releases. The choice depends on your situation, not on which proposal contains the longest service list.

Before requesting final terms, turn the discussion into a one-page brief: business objective, page scope, access, deliverables, approval owners, reporting definitions and review date. Ask the agency to correct anything it interprets differently. That shared document gives the relationship a practical starting point and gives you something concrete to review after the first cycle of work.