OPERATIONS

SEO SOP Templates: 6 Standard Operating Procedures You Can Use

Six practical SEO SOP templates with owner, frequency, steps and definition of done, plus how to structure an SEO wiki and roll out SOPs your team will use.

Ajay Padhy
·14+ Yrs in SEO & Growth
Updated 7 October 2026·⏱️ 10 min read·LinkedIn ↗
A binder of standard operating procedure templates for SEO tasks

Short answer

An SEO SOP (standard operating procedure) is a short, written standard for a recurring SEO task: its purpose, owner, frequency, inputs, steps and definition of done. The most useful ones cover monthly technical health checks, on-page optimisation, content briefs, internal linking, reporting and pre-launch QA. Keep each to a couple of screens, store them in one wiki, and review them quarterly.

Key takeaways

  • Every SEO SOP needs six fields: purpose, owner, frequency, inputs, steps and a definition of done; the definition of done is what makes it checkable.
  • Start with the six tasks that repeat most often: technical health checks, on-page optimisation, content briefs, internal linking, reporting and pre-launch QA.
  • An SOP longer than a couple of screens will not be used during real work; link out to detail instead of including it.
  • Roll SOPs out by piloting with the people who do the work, then tying them to QA and task templates so using them is the default.
  • Each SOP needs a named owner and a quarterly review, or it drifts out of date and people stop trusting it.
In this article (6 sections)
  1. 1What makes a good SEO SOP?
  2. 2Six SEO SOP templates you can copy
  3. 3How to roll out SOPs so people actually use them
  4. 4How to structure an SEO wiki
  5. 5The process SOPs I've written
  6. 6When SOPs will not fix the problem

An SEO SOP is a written standard for a task your team does repeatedly. It answers five questions: why we do this, who owns it, how often, what steps, and how we know it is done properly. That sounds bureaucratic, but the alternative is worse: quality that depends on who happened to pick up the task, and knowledge that walks out of the door when someone leaves.

When I led international SEO delivery teams, and later as Head of SEO, SOPs were the foundation of everything else: QA scoring, onboarding, automation and reporting. This article gives you six working templates, then explains how to roll them out so people actually use them.

What makes a good SEO SOP?

Most SOPs fail for one of two reasons. Either they are so long nobody reads them, or so vague ("optimise the page") that two people follow them and produce different work.

Every template below uses the same six fields:

FieldWhat it answersCommon mistake
PurposeWhy this task exists and what outcome it protectsSkipped, so people cut corners they do not understand
OwnerWho does it and who keeps the SOP current"The team", which means nobody
FrequencyWhen it runs or what triggers itLeft implicit
InputsTools, access and documents needed before startingDiscovered halfway through
StepsThe ordered actions, specific enough to checkWritten as goals, not actions
Definition of doneWhat must be true before the task is closedMissing, so "done" is subjective

The definition of done is the most important field. It is what your QA reviewer scores against, and what makes the SEO process checkable rather than a matter of opinion.

Six SEO SOP templates you can copy

Each standard operating procedure below is written to be pasted into your wiki and adapted. Change tools, owners and frequencies to fit your team; keep the structure.

SOP 1: Monthly technical health check

  • Purpose: Catch crawl, indexing and performance problems before they affect traffic.
  • Owner: Technical SEO specialist; account lead reviews findings.
  • Frequency: Monthly, plus after any major site release.
  • Inputs: Screaming Frog, Google Search Console access, GA4, previous month's health check.

Steps:

  1. Run a full crawl with the saved configuration for this site (JavaScript rendering on if the site needs it).
  2. Export and compare against last month: new 4xx and 5xx errors, redirect chains, noindex pages, canonical changes, orphaned pages.
  3. In Search Console, review page indexing for new exclusions, Core Web Vitals for failing URL groups, and any manual actions or security issues.
  4. Check robots.txt and XML sitemaps for unexpected changes.
  5. Log each issue with URL examples, impact (high, medium, low) and recommended fix.
  6. Raise high-impact issues with the developer or client the same day.

Definition of done: Crawl saved; issue log updated with severity and owner for every item; high-impact issues raised; month-on-month summary written in three to five lines.

SOP 2: On-page optimisation

  • Purpose: Align a page with its target keyword cluster and search intent.
  • Owner: SEO executive; QA reviewer samples completed tasks.
  • Frequency: Per page, as scheduled in the monthly plan.
  • Inputs: Approved keyword map, SERP review notes, CMS access, brand and style guide.

Steps:

  1. Confirm the target page and cluster match the keyword map. If not, stop and flag.
  2. Review the current top-ranking pages for the primary term to understand intent and expected content.
  3. Rewrite the title tag and meta description: unique, primary term included, written to earn the click.
  4. Check H1 and H2s reflect the cluster and answer the questions searchers ask.
  5. Improve body content where it fails the intent; do not just insert keywords.
  6. Add or fix internal links to and from relevant pages with descriptive anchors.
  7. Validate structured data if the template uses it.
  8. Confirm the page is indexable and canonical is correct, then log the change with the date.

Definition of done: All changes live and verified on the live URL; change log updated; no critical items from the QA scorecard missing.

SOP 3: Content brief

  • Purpose: Give writers everything they need to produce a page that can rank, first time.
  • Owner: SEO strategist or content lead.
  • Frequency: Per new article or landing page.
  • Inputs: Keyword research, SERP review, existing site content, audience notes.

Steps:

  1. State the primary keyword, three to six secondary terms and the search intent in one sentence.
  2. Summarise what the top-ranking pages cover and what they miss.
  3. Define the target reader and the one action you want them to take.
  4. Provide a proposed H2 outline, including questions to answer directly.
  5. List internal links to include and pages that should link to the new piece.
  6. Note facts, examples or first-hand experience to include, and claims to avoid.
  7. Set word-count range, tone, and any market-specific spelling or terminology.

Definition of done: Brief approved by the content lead; a writer could start without asking a clarifying question.

SOP 4: Internal linking pass

  • Purpose: Help important pages get discovered, crawled and understood in context.
  • Owner: SEO executive.
  • Frequency: Quarterly per site, and whenever a priority page is published.
  • Inputs: Crawl data with inlink counts, list of priority pages, keyword map.

Steps:

  1. Export inlink counts from the crawl and identify priority pages with few internal links.
  2. Find relevant source pages using a site search for the page's topic and related terms.
  3. Add contextual links with descriptive anchor text; avoid repeating the exact same anchor everywhere.
  4. Fix any internal links that point to redirects or broken URLs.
  5. Check the new page is linked from its parent category or hub.
  6. Re-crawl to confirm inlink counts changed as expected.

Definition of done: Every priority page has contextual links from relevant pages; no internal links to redirects or errors in the sections touched; changes logged.

SOP 5: Monthly SEO reporting

  • Purpose: Show the client what changed, why, and what happens next, in terms of business outcomes.
  • Owner: Account lead; data pulled automatically where possible.
  • Frequency: Monthly.
  • Inputs: Looker Studio dashboard, Search Console, GA4, work log, previous report.

Steps:

  1. Refresh the dashboard and check data sources connected correctly and dates are right.
  2. Compare organic clicks, conversions and priority rankings with last month and last year.
  3. Write a three-line summary: what moved, why we think it moved, what we are doing next.
  4. List work completed, linked to the work log.
  5. Flag risks or blockers that need the client's input.
  6. Have a second person check numbers and wording before sending.

Definition of done: Report sent on the agreed date; every number checked; summary written in plain language; next month's priorities stated.

This is the task most worth automating. I cover the reporting side in my SEO reporting guide, and the data-pulling side in SEO reporting automation.

SOP 6: Pre-launch SEO QA

  • Purpose: Stop new pages, templates or sites going live with SEO-breaking errors.
  • Owner: Technical SEO specialist; sign-off from account lead.
  • Frequency: Before every release that changes templates, URLs or significant content.
  • Inputs: Staging access, release notes, redirect map if URLs change.

Steps:

  1. Confirm staging is protected, and list exactly which noindex or robots.txt rules must be removed at launch.
  2. Crawl staging: check titles, headings, canonicals, hreflang, structured data and internal links on each template.
  3. Compare content with the live version for anything removed unintentionally.
  4. Test redirects if URLs change.
  5. Confirm analytics and tag manager are present.
  6. After launch, check robots.txt, meta robots and a sample of live templates within the hour.

Definition of done: Checklist signed off before release; post-launch checks completed and recorded the same day.

For full migrations, this expands into a much longer process; see my website migration SEO checklist.

How to roll out SOPs so people actually use them

Writing SOPs is the easy part. Getting a team to use them is where most initiatives stall. What has worked for me:

  1. Write them with the people who do the work. Draft with your best practitioner, then pilot with two or three others. If they find a step unrealistic, change it.
  2. Start with three, not thirty. Pick the tasks with the most volume or the most errors, prove the value, then expand.
  3. Build them into the tools. Turn each SOP into a task template in your project management tool (Wrike, Asana or similar) so the steps appear as a checklist when the task is created.
  4. Connect them to QA. When the QA scorecard uses the SOP's definition of done, the SOP stops being optional.
  5. Use them in onboarding. New starters learn from SOPs and shadow a senior, rather than learning from whoever is available.
  6. Treat every recurring QA error as an SOP bug. Update the document, note what changed, and tell the team.

The link between SOPs and QA is what made the difference on the international teams I led, where execution quality moved from around 70% to 98%. I explain that system in SEO quality at scale.

How to structure an SEO wiki

SOPs are only useful if people can find them in under a minute. Keep them in one wiki (Notion, Confluence, Google Sites or similar) with a predictable structure:

  • Start here: how the team works, who owns what, how to request changes to an SOP
  • Technical SEO: health checks, pre-launch QA, migrations, site speed
  • On-page and content: on-page optimisation, content briefs, internal linking, localisation rules
  • Reporting: monthly reporting, dashboard definitions, how to explain common changes
  • Tools and access: saved crawl configurations, templates, account access process
  • Market glossaries: preferred terms and spelling per country, for international accounts

Each page should show its owner, last review date and version number at the top. Review every SOP quarterly, and archive old ones instead of leaving them in place.

The process SOPs I've written

The six templates above are task SOPs: they standardise one piece of SEO work. Above them sits a second layer. These are process SOPs that span teams (sales, delivery, account management and people), not department SOPs owned by one function. I have written 13, in three groups. Each line below describes what the process controls, not its steps.

Client lifecycle

  • Client Onboarding Process — how a new client is set up, from kick-off and access to agreed goals and baseline.
  • Client Churn Process — how at-risk clients are identified and handled, and how the reasons clients leave are recorded.
  • Proposal & Sales Process — how opportunities are scoped and proposed, and how they are handed to delivery.
  • Client Communication & Reporting Process — how and when clients hear from the team, and the structure of their reports.
  • Crisis Management Process — how urgent problems are escalated, owned and communicated.

Delivery

  • Team Workflow & Task Delegation Process — how work is assigned, tracked and handed between people.
  • Quality Assurance (QA) Process — how delivered work is reviewed, scored and corrected.
  • Website Migration & Change Management Process — how migrations and significant site changes are planned, approved and checked.
  • Automation & AI Implementation Process — how tasks are chosen for automation or AI, and how those systems are tested and handed over.

People

  • Training & Upskilling Process — how skills gaps are identified and closed.
  • New Joiner Onboarding Process — how new team members get access and context and reach independent work.
  • Knowledge Transfer (KT) Process — how account and task knowledge moves when someone changes role or leaves.
  • Probation Confirmation Process — how a new joiner's probation is assessed and confirmed.

These are internal documents and are not published as downloads. The task templates above are the part designed to be copied.

When SOPs will not fix the problem

Honest limit: SOPs do not fix an overloaded team, unclear strategy or a client who changes direction every month. If people skip steps because they have too many accounts, the answer is capacity, not a better document. And an SOP cannot substitute for judgement on novel problems; it standardises the routine so senior people have time for the hard cases.

If you want help designing SOPs, QA and the workflow around them, that is the core of my marketing operations consulting. Where the steps are mechanical, many can be scripted or scheduled through SEO automation, which is where the reporting SOP above usually ends up.

FAQ

Frequently asked questions

Quick answers to common questions about seo sop.

An SEO SOP, or standard operating procedure, is a short written standard for a recurring SEO task. It states the purpose, owner, frequency, inputs, step-by-step actions and a definition of done. It ensures the task is done the same way regardless of who does it, and gives quality reviewers a clear standard to check against.

Start with the tasks that repeat most often or cause the most errors: monthly technical health checks, on-page optimisation, content briefs, internal linking, reporting and pre-launch QA. Add SOPs for migrations, local listings or link reviews once the first set is being used consistently and tied into your QA process.

Short enough to use during real work, usually one or two screens. Include the six core fields and specific, checkable steps. Put detailed background, screenshots or training material on separate linked pages, so the SOP itself stays scannable. If people need to scroll through pages of text, they will stop using it.

A useful SOP has six components: the purpose of the task, a named owner, the frequency or trigger, the inputs needed before starting, the ordered steps, and a definition of done. The definition of done matters most, because it is what a reviewer checks the finished work against.

ChatGPT and similar tools are useful for producing a first draft of an SOP from your notes or a recorded walkthrough. The draft still needs a human owner who tests it against real work, corrects the steps and keeps it current. An untested AI draft tends to read well but miss the details that cause errors.

Write them with the people doing the work, start with a small set, build them into task templates in your project tool, use them in onboarding, and connect them to QA scoring. When QA findings lead to SOP updates, the team sees the documents improving and treats them as useful rather than bureaucratic.

Have a growth problem worth solving?

Tell me where you're stuck. On a 30-minute intro call I'll tell you where I think the constraint is and what I'd look at first — whether or not we end up working together.