SEO Implementation / Practical guide
Your SEO audit is complete. Who implements the fixes?
A finished audit is not a changed website. Here is how I would agree the delivery roles, brief the work and verify the repair with the team you already have.
The report is finished. The website has not changed.
You have the audit, a spreadsheet of recommendations and several people waiting for a brief. The developer needs to know the expected behaviour. The writer needs an approved page purpose. The business owner wants to know what the next invoice buys. Until those questions are settled, nobody has a clear plan for doing the work.
When I review this situation, I separate three responsibilities: deciding what needs to change, making the change and verifying that it worked. One person can hold more than one role, but the roles still need to be explicit. Otherwise, a recommendation can move between the consultant and developer for weeks without anyone being accountable for the next step.
This guide is about organising the implementation, not choosing which warning deserves attention first. For that decision, use the SEO audit prioritisation guide. Here, I want to help you turn the approved work into a scope your team can deliver and check.
1. Give each fix to the person who can make it
An SEO specialist may identify a canonical problem without being the person who should edit your ecommerce platform. A developer may be able to change a template without knowing whether the canonical points to the page the business actually wants indexed. The two need to work together; neither should have to guess the other’s requirements.
Use the table below to assign the work to named people. One person may cover several roles.
| Work type | Typical implementer | What the SEO reviewer supplies |
|---|---|---|
| Templates, redirects and canonical output | Developer or platform specialist | Affected examples, intended signals, exceptions and tests. |
| Page copy, titles and internal links | Content editor with the business owner | Page purpose, missing information and link requirements; factual claims need owner approval. |
| Robots rules, firewall or hosting behaviour | Responsible platform, hosting or security administrator | Reproducible access evidence and the specific public path involved; preserve private-path protection. |
| Analytics and enquiry-event measurement | Analytics specialist or authorised developer | Event definitions, test cases and known data limitations. |
| Business-profile information | Authorised profile or business owner | Verified correction request and evidence of the inconsistency. |
| Release approval and acceptance | Named business approver and reviewer | A clear pass condition, regression checks and follow-up responsibility. |
Keep privileges proportionate. Reviewing a report is not a reason to give everyone server access. Diagnosis can often begin with read-only evidence. Write access, deployment permissions and access to private customer information should follow the agreed task and your normal approval process.
If the distinction between page content, crawling and templates is unclear, the technical SEO guide explains the underlying areas. It is better to clarify the component before asking somebody to quote for changing it.
2. Choose how the work will be delivered
Choose the arrangement that fits your team’s skills, available time and the work involved. You may not need to replace the people already looking after the website.
Your existing team implements; the SEO reviewer advises
This can work when your developer and editor know the website well. Agree who turns audit findings into tickets, who answers clarification questions and how many review rounds are included. Advisory time is not the same as development capacity. If the team has no release slot, another report will not solve that bottleneck.
Responsibility: Your developer or editor makes the change; the SEO adviser checks it.
Ask before committing: Who reserves delivery time, and how many clarification and review rounds are included?
A specialist implements a defined group of fixes
This may suit a platform-specific or shared-template problem. Quote for the affected behaviour, not an undefined promise to “fix technical SEO”. The brief should state which templates and exceptions are covered, what testing is included and who retains responsibility for hosting, security and other suppliers.
Responsibility: The platform specialist makes the change; your business or release lead approves it.
Ask before committing: Which templates, exceptions and post-release checks are included in the quote?
One provider coordinates diagnosis, implementation and review
This means fewer handovers between suppliers, but you still need to know what changed. Ask who actually makes the changes, how they will be recorded and who signs off. Where practical, use a second person to review higher-risk work. A small team can still use a written checklist and explicit business approval when a separate reviewer is unavailable.
Responsibility: The lead provider coordinates the work; the person your business authorises approves the release.
Ask before committing: Who performs the changes, who reviews them and where is the release evidence recorded?
My SEO consulting work can focus on independent direction and review while you keep your team. Any implementation responsibility, access and fee should be agreed separately. If you want me to arrange or make changes, we need to agree that work separately.
3. Agree exactly what the implementation quote covers
A count of audit warnings is a poor unit of work. Ten warnings may share one template cause; one warning may affect several templates and require a careful release. Before comparing prices, ask each provider to work from the same confirmed scope.
- Included behaviour: which pages, templates or records will change, and what they should do afterwards.
- Exclusions: content writing, design changes, paid services, platform upgrades and unrelated repairs that are not included.
- Dependencies: approved copy, platform access, another supplier’s action or a release window.
- Testing: affected examples, unaffected controls, enquiry journeys and relevant device checks.
- Approval and rollback: who can release, which regression would stop the release and how the previous state can be restored.
- Handover: change record, test evidence, unresolved issues and any maintenance obligation.
Ask what happens if the developer finds a larger problem. They should explain it and agree any extra work with you before proceeding.
There is no useful universal price or completion time for this work. A content correction, a platform migration and a shared-template repair have different dependencies. Ask for an estimate after the implementer has enough evidence to understand the affected component.
4. Give the implementer a brief they can use
Here is a fictional example of how I would brief the work.
Example: service-page enquiry links point to an old form
The recommendation: repair the enquiry path on the affected service-page template. The audit identifies three sample URLs where the main enquiry button opens a retired destination.
The SEO reviewer’s brief: identify the affected template and approved replacement destination, record the existing behaviour, and state the expected visitor journey. Confirm with the business owner that the new form is appropriate for those services.
The implementer’s task: locate the shared link setting or template, make the scoped repair in the normal test environment and identify whether other pages inherit the setting. Do not replace every link on the site just because the same old URL appears somewhere else.
The approval: the owner approves the destination and a controlled test submission. The release owner schedules the change and retains the previous configuration.
How we would check the fix: affected buttons open the correct form, keyboard activation works, one approved test reaches the intended recipient, and an unaffected service page still behaves as expected. Record the test details without storing unnecessary private enquiry data.
The follow-up: the reviewer confirms the production repair and the analytics owner checks the relevant event definition. Whether suitable enquiries increase is a later business observation, not a prerequisite for declaring the broken link repaired.
This is the level of detail that helps someone estimate and deliver the work. “Improve conversions” would not tell the developer which behaviour is wrong or give the business owner a fair acceptance test.
5. Close the ticket against evidence, not a tool score
Keep the before-and-after evidence attached to the same task. I want to see the approved requirement, the actual release, the checks performed and any exceptions. A cleaner crawl report is useful when it reflects the intended repair; it is not a substitute for checking the real visitor journey.
- Confirm the intended change. Inspect the affected production page, response or record, not just the test environment.
- Check what must stay unchanged. Include unaffected examples and important actions such as navigation, forms or checkout where relevant.
- Record the release. Note the date, owner, scope, evidence and remaining dependencies in the project tracker.
- Assign the follow-up. Give indexing observations and business measurement their own owner and review point.
For changes affecting search, distinguish a repaired website condition from Google’s later processing. Google’s recrawl guidance explains that requesting a crawl does not guarantee inclusion. Repeated requests do not turn an uncertain outcome into a guaranteed one.
Likewise, a ranking change the next day does not establish that your release caused it. Keep the change log alongside the available search, enquiry and sales evidence. With limited traffic, be honest about what the sample can support instead of claiming a percentage improvement from a handful of visits.
What to agree before work starts
Use the interactive checklist below with the people doing the work. Agree who will resolve anything still missing.
If the original report does not support those decisions, ask its author to explain the recommendation before commissioning a replacement audit. You may need a better handover, not a second diagnosis of the same problem.
Ready for implementation?
Use this checklist to find what still needs agreeing before the work starts.
Common questions about implementing an SEO audit
Does an SEO audit normally include fixing the issues?
Not automatically. The agreed scope determines whether the fee covers diagnosis, a handover, implementation or later review. Ask for those responsibilities and deliverables in writing before work begins.
Can my existing developer implement the audit?
Often, yes, if they know the platform and have time for the work. The SEO specialist should explain the problem and how the fix will be checked; your developer should confirm what they need to make it happen.
Should I give the SEO consultant administrator access?
Only when the agreed task requires it and the responsible owner approves it. Start with proportionate access for diagnosis. Editing, deployment and private-data permissions are separate decisions, not automatic conditions of reviewing an audit.
Who decides whether an SEO fix is complete?
Agree who approves the change and who checks it before work begins. A fix is complete when it works on the live site and the relevant checks pass. Indexing changes and business results may take longer to assess.
Do we need another audit before implementing the first one?
Not necessarily. First check whether the original findings are current, reproducible and clear enough to brief. An independent review may help with uncertainty, but repeating the whole audit is not the default answer to a missing implementation plan.
Sources
Google’s hiring and recrawl guidance was checked on 16 October 2026. For your project, name the people who will make the changes, approve them and check the result.