How to evaluate an agency for SEO and development work
Assess an agency through a bounded technical exercise, evidence behind its claims, and a clear plan for ownership, verification, and handover.
Use the same problem for every candidate
An agency pitch is difficult to compare when one supplier describes rankings, another proposes a redesign, and a third estimates implementation hours. Give each the same short brief: the business outcome, site constraints, relevant data access, and a sample problem. Ask for a proposed investigation and delivery boundary before comparing price.
A useful example is a service page being replaced during a redesign. The candidate should explain how it will identify the existing URL’s role, decide whether the replacement serves the same intent, implement the change, and check what happened. A visual mockup answers only part of that problem.
Request evidence with a limited audit
Google recommends asking prospective SEOs for a technical and search audit, an explanation of proposed changes, and realistic expectations. It also warns against guarantees of a number-one ranking. Treat those as practical interview prompts: ask what the agency can control and what it will measure without promising a search outcome.
A paid, bounded exercise can produce a useful artifact without becoming a free redesign competition. Specify the pages in scope, the time limit, and the required evidence. Keep pre-engagement access read-only where possible, and agree how findings will be shared. Do not hand over production publishing rights just to obtain an estimate.
Ask for a change that can be checked
The following checklist is an illustrative assessment brief. It asks the candidate to connect an SEO recommendation to implementation and validation. It is not a guarantee that a redirect preserves rankings.
scenario: replace_a_service_page_during_redesign
inputs:
old_path: /services/legacy-offer
proposed_path: /services/replacement-offer
candidate_deliverables:
- Explain whether the pages serve equivalent user intent
- Describe redirect behavior or justify a different outcome
- Identify internal links and sitemap entries to update
- Define pre-release checks and post-release monitoring
- Name the owner of implementation and incident response
review_questions:
- Which statements are observations and which are assumptions?
- Can another developer reproduce the finding?
- What evidence would make you change the recommendation?
Inspect the evidence behind results
For a case study, request the measurement period, baseline, changes made, and relevant limitations. Search traffic may be affected by seasonality, brand campaigns, site changes, or search-system updates. Ask whether the reported metric is impressions, clicks, enquiries, or qualified enquiries, and how the agency connected it to the client’s objective.
Google’s site-move guidance covers URL mapping, redirects, internal links, sitemaps, and monitoring. A candidate should be able to turn those concerns into a reviewable release checklist. Evaluate whether its explanation is technically grounded; an elaborate story without reproducible observations is weak evidence.
Evaluate the working arrangement too
Ask who reviews code, who can release it, and how failed changes are diagnosed. Request an example of a redacted change proposal or handover rather than confidential client material. Clarify repository, domain, analytics, and content ownership so the client can continue operating after the engagement.
Record selection reasons using comparable criteria: diagnosis quality, delivery scope, validation plan, communication, cost assumptions, and handover. Mark unknowns rather than assigning optimistic scores. The smallest useful next step may be a narrow engagement with a defined acceptance boundary, especially when the agency has not yet seen enough evidence to estimate a full redesign.