A technical SEO engagement is useful when it leaves the firm with a verified repair, a defensible decision, or both. A crawler export with 2,000 warnings may create work without showing which practice pages, office pages, attorney profiles, or intake paths are actually at risk.
Buy the investigation around a business problem. Then make evidence, implementation, acceptance, and handoff part of the same scope.
Write the incident brief before requesting proposals
Use the technical SEO problem guide to describe the failure, the technical-debt framework to identify recurring burden, and the Core Web Vitals guide when performance evidence is part of the incident.
Start with what changed, what appears affected, and what the firm must protect.
Business concern: visibility and qualified inquiries for two priority practices fell after a redesign.
Change window: staging launch and domain cutover occurred May 4–6.
Priority inventory: 18 practice pages, 9 office pages, 26 attorney profiles, and 41 guides with known links or prior search activity.
Known uncertainty: analytics, content, search demand, seasonality, and technical release changes may all contribute.
Needed decision: identify repairable launch defects, implement approved corrections, and decide whether remaining loss needs content, authority, local, intake, or longer observation.
That brief prevents a routine “health audit” from replacing an incident investigation. It also stops the provider from promising that every visibility change has one technical cause.
Choose the engagement by who can finish the work
Scroll sideways to review every column.Each row is shown as a labeled card.
| Engagement | Useful when | Completion evidence |
|---|---|---|
| Focused diagnosis | A release, template, or URL group has a defined symptom | Reproducible cause evidence, affected scope, repair specification |
| Full audit | The site has unclear ownership or accumulated problems | Reconciled inventory, prioritized findings, dependencies, decision log |
| Audit plus remediation | The firm lacks technical implementation capacity | Approved fixes in staging/live, regression checks, final verification |
| Migration support | URLs, templates, CMS, domain, or navigation will change | Baseline, redirect/content map, launch controls, post-launch checks |
| Ongoing technical stewardship | Releases regularly affect search-critical pages | Release review, monitoring ownership, incident response, maintenance record |
An audit-only engagement can be right when a trusted development team is ready. It is a poor purchase when nobody can translate recommendations into safe releases.
Make the provider show a complete finding
Give each finalist one known URL family and ask for a sample finding. Compare the answer itself.
Evasive answer:
“The site has 143 canonical errors. Fix canonicals to improve rankings.”
Reviewable answer:
“Fourteen office-practice pages declare the national practice page as canonical, while navigation and sitemap entries treat the office pages as distinct. Google may choose a different canonical regardless of the declaration. Before changing code, the firm must decide whether each office page serves a distinct market need. For pages approved as distinct, update the template output, retain self-referencing canonical signals, verify the rendered HTML and sitemap, and monitor Google's selected canonical after recrawl. For duplicative pages, choose a consolidation path rather than changing the tag alone.”
The second answer separates business ownership, technical evidence, implementation, and later search observation. Google's canonical guidance describes signals and notes that canonical choice remains Google's decision. Read the current canonical documentation.
Require every consequential finding to include:
- affected URL or template and estimated extent;
- observed versus intended behavior;
- live, rendered, CMS, log, or search evidence;
- business consequence and uncertainty;
- proposed repair and dependencies;
- implementation owner;
- staging and live acceptance test; and
- monitoring period or next decision.
Judge the inventory, not the crawler count
Map relationships with the website architecture guide and keep schema markup subordinate to visible page truth.
A sitemap-only review misses orphaned and historical URLs. A homepage crawl may miss disconnected campaign or legacy sections. Search Console includes old observations, while the CMS can contain unpublished, redirected, or duplicate records.
The provider should explain how it will reconcile CMS exports, sitemaps, internal crawling, response codes, canonical signals, Search Console, relevant analytics, migration maps, and logs when a specific crawl question justifies them. The result should identify current owners, historical predecessors, intended exclusions, and unknowns.
One faulty template can produce hundreds of repeated symptoms. One historically valuable orphan may matter more than 500 harmless parameter URLs. Ask how prioritization distinguishes count from consequence.
Normalize proposals with internal work included
Consider two fictional scopes for the redesign incident. The firm values internal marketing time at $100 per hour and has a developer available at $175 per hour. Those are planning assumptions, not Juris Digital prices or accounting rules.
Scroll sideways to review every column.Each row is shown as a labeled card.
| Item | Provider A | Provider B |
|---|---|---|
| External audit fee | $12,000 | $20,000 |
| Included implementation | None | Up to 40 scoped development hours |
| Separate development estimate | 40 × $175 = $7,000 | Included |
| Internal manager time | 8 × $100 = $800 | 12 × $100 = $1,200 |
| Planning total | $19,800 | $21,200 |
| Priority-URL baseline | Sitemap only | Reconciled priority/history set |
| Release verification | Recommendations call | Staging test, live test, 30-day search review |
| Remaining uncertainty | Not specified | Content/local/authority/intake branches recorded |
Provider A is $8,000 cheaper on the audit invoice but only $1,400 cheaper in this planning view after expected implementation and internal time. Provider B may be the better incident scope because it owns the repair path. It is still the wrong choice if “up to 40 hours” excludes the actual CMS work or if the firm cannot provide the additional review time.
Do not turn the example into a benchmark. Replace every number with the real proposal, likely development effort, internal time, tool/access cost, and rework rule.
Put access, change control, and rights through gates
Before scoring polish or price, require:
- individual, least-necessary access rather than provider-only ownership;
- a baseline and rollback path before changes;
- staging where the risk justifies it;
- approval rights for redirects, removals, canonical decisions, and template changes;
- protection for analytics, consent, forms, call routing, accessibility, and mobile use;
- portable inventory, findings, tickets, maps, tests, and credentials at exit; and
- a correction process when a recommendation or implementation is wrong.
Google's hiring guidance recommends read-only Search Console access during an audit and warns against ranking guarantees. Read Google's guide to hiring an SEO. The broader law-firm agency buyer guide helps evaluate commercial and working-relationship terms beyond the technical scope.
Define acceptance before the fix
“Issue closed” should mean something another person can verify.
For an accidental noindex on a practice template, acceptance might require: the approved URLs return the intended status; the directive is absent from delivered and rendered output; canonical and sitemap signals match the approved owner; internal links still reach the pages; the form and analytics path still work; and the release record lists the exact version. Google's later crawl, indexing, and ranking are monitored separately.
For a redirect repair, test old URL, each hop, final destination, response, page equivalence, canonical, internal links, and loops. For a rendering defect, test the essential content and links in delivered and rendered states. For performance work, define the page type, device population, field/lab evidence, interaction, and regression threshold.
Do not use ranking improvement as the acceptance test for correct code. Search results can change for many reasons, and a technically valid release does not guarantee indexing or rank.
Buy a bounded first phase
Place accepted work inside the law-firm SEO roadmap and the complete SEO strategy so a technical finding has an owner and sequence.
For an unclear incident, a useful first phase can last two weeks and end with a decision rather than an enormous report. Specify the priority inventory, access, change timeline, three representative templates, evidence standard, daily escalation for high-risk defects, implementation estimate, and decision meeting.
The ending choices are concrete:
- repair now when a reproducible defect affects priority pages;
- stage and test when the change carries meaningful regression risk;
- monitor when implementation is correct but search processing or cohorts need time;
- move the problem to content, local, authority, design, or intake when technical evidence does not support the original theory; or
- stop when the proposed work cannot change a meaningful firm decision.
Juris Digital's current law firm SEO service connects technical/site foundations with strategy, content, local visibility, authority, and measurement. Bring the incident brief, priority URLs, change history, current access, development capacity, and competing scopes. We can help define the evidence and repair path; the proposal will state which diagnosis, implementation, and verification work is included.
