Writing Down Your SEO Standards

Most organizations already have SEO standards. They just live in the wrong place: in the head of one specialist, in a slide deck from an agency engagement three years ago, or scattered across old tickets that nobody will ever search. Documenting SEO standards means turning that scattered knowledge into written requirements that tell content writers, editors, designers and developers exactly what search needs from their work, in the tools and documents they already use every day.

This briefing is for marketing leads, product owners, heads of content and engineering managers who keep seeing the same search problems come back after they were fixed. It is also for the SEO practitioner who has become a bottleneck, reviewing every page by hand because the rules exist nowhere except in their own memory. The goal is not a longer document. The goal is a set of short, specific, testable standards that survive staff turnover, redesigns and platform changes.

The structure follows an expert briefing: an executive summary first, then the technical depth that specialists need to write and enforce standards, then the implications for budgets, risk and staffing.

Executive Summary: Documenting SEO Standards in One Page

If you read nothing else, read this section. Search performance depends on hundreds of small decisions made by people who are not SEO specialists: a developer choosing how a filter changes the URL, a writer deciding what goes in a page title, a designer replacing a text heading with an image. When those people do not know what search requires, they make reasonable choices that happen to be wrong, and the specialist cleans up afterward. When the specialist leaves, nobody cleans up at all.

Written standards solve that problem by moving the requirement to the point where the decision is made. The core recommendations are short:

• Put technical requirements next to the components they govern. A rule about how the article template renders its title element belongs in the documentation for that template, not in a separate SEO wiki that developers never open.
• Write content standards with examples. A rule such as "write descriptive titles" is useless without a good and a bad example side by side. Examples are what people copy.
• Add search checks to the launch checklist. A standard that is checked only after launch is an audit finding, not a standard. The check has to happen before the page or feature ships.
• Review standards when search guidance changes. Search engines update their documentation. A standard written once and never revisited slowly becomes a source of wrong advice.
• Train new team members on the standards. Documentation that nobody is introduced to is documentation that nobody reads.

The business case is equally short. Every regression of a fixed search problem costs the same diagnosis and repair time a second time, plus whatever traffic was lost in between. Standards reduce that repeat cost and make search quality less dependent on any single person. When fixes keep regressing despite the effort, that is the signal to bring in outside help to set up the system, not just to fix the latest symptom.

Why Search Knowledge Disappears When It Lives With One Specialist

The failure pattern is familiar to anyone who has worked on a mid-sized website for more than a couple of years. A specialist spots a problem, perhaps that category pages are generating thousands of near-duplicate URLs through sort parameters. They write a ticket, a developer fixes it, and traffic recovers. Eighteen months later the site gets a new filtering feature, built by a different developer who never saw the original ticket, and the same duplication returns in a slightly different form.

Nothing about that sequence involves negligence. The second developer did good work by the standards they were given. The problem is that the standard itself was never written anywhere the developer would look. It lived in a closed ticket and in the specialist's memory.

The three ways undocumented knowledge fails

• It leaves with people. Staff turnover, agency changes and reorganizations remove the only copy of the rule. The new team rediscovers problems the old team had already solved.
• It does not scale. One specialist can review a handful of pages a week. A content team publishing dozens of pieces and an engineering team shipping weekly releases will outrun any single reviewer.
• It arrives too late. When the rule is only in the specialist's head, it can only be applied when the specialist sees the work, which is usually after it is built, sometimes after it is live and indexed.

These failures compound. A team that keeps rediscovering the same problems starts to see SEO as unpredictable, and it becomes harder to argue for search work in planning meetings. If you are already fighting for roadmap space, the guide on getting SEO work prioritized covers how to frame that case; written standards make it easier because they turn vague "SEO concerns" into specific, checkable requirements.

What a Complete Standard Set Contains

A useful standard set is not one document. It is four layers, each stored where its audience already works. Mixing them into a single long SEO manual is the most common reason standards go unread: developers skip the writing advice, writers skip the rendering rules, and nobody reaches the checklist at the end.

The table is also a quick diagnostic. If you can name where each layer lives today and who owns it, you have a standard set. If one of the cells reads "in someone's head" or "in an old audit PDF," that is where regressions will come from.

Scope: what belongs in standards and what does not

Standards should cover recurring decisions, not strategy. Keyword targeting for a specific campaign, the content calendar and quarterly priorities change too often to be standards; they belong in plans. A standard answers a question that comes up again and again: how should the title element be built on this template, what happens to the URL when a product is discontinued, how many H1 elements can a page have, what alternative text does a decorative image need. If a question is asked more than twice, it deserves a written answer.

Technical Standards That Live With Components

The single most effective change most organizations can make is to stop keeping technical SEO rules in a separate SEO document and start writing them into the documentation for each template and component. Developers consult component documentation when they build or change a component. They rarely consult an SEO wiki. Putting the rule where the work happens is what makes it stick.

Google's own Search Central documentation and Search Essentials are the authoritative reference for what the search engine requires, and your standards should cite the specific pages they depend on. That citation matters later: when Google changes a page, you know which of your standards to review.

Page head and metadata

For each page template, document how the title element, meta description, canonical link and robots directives are generated. Be specific about the source of each value. For example: "Title element = the CMS SEO title field if populated, otherwise the page headline, followed by a separator and the brand name. The brand suffix is dropped if the combined string would exceed the configured limit." Write down what happens in edge cases: empty fields, very long headlines, paginated views, search result pages, and pages behind a login.

URLs, parameters and canonicalization

Document the URL pattern for every content type, the parameters the site generates (sorting, filtering, tracking, session), and how each is handled: canonicalized to the clean URL, blocked from crawling, or indexable by design. This is where the category-filter regression described earlier would have been prevented. A new developer building a filter would find, in the listing component's documentation, a clear rule: "Filter and sort parameters must not create new indexable URLs unless the combination is on the approved list in this section."

Links and navigation

State that navigational and in-content links must be real anchor elements with an href attribute pointing to a crawlable URL, not click handlers on other elements. Specify how breadcrumbs are built, how pagination links work, and what happens to links when content is unpublished. These are small rules that are easy to break during a front-end rebuild.

Rendering and JavaScript

If the site relies on client-side rendering, the standards need to state which content must be present in the server response, which may load later, and how to test the difference. This is one of the areas where undocumented knowledge causes the largest regressions, because a framework upgrade can silently change rendering behavior. Teams building on JavaScript-heavy stacks often benefit from specialist JavaScript SEO support to write these rules correctly the first time.

Redirects, status codes and removals

Document what happens when a URL changes or content is retired: which status code is returned, who maintains the redirect map, and how redirect chains are prevented. Write the rule for out-of-stock products, expired events and merged articles separately, because each one tends to be handled by a different team.

Structured data

For each template that outputs structured data, document the type, the required and recommended properties, the source field for each property, and the validation step. Structured data breaks quietly when a CMS field is renamed, so the component documentation should name the fields it depends on.

Content Standards: Titles, Headings and Structure With Worked Examples

Content standards govern the decisions writers and editors make on every page. The reference points are well established: titles, headings, structure, internal linking and descriptions all need written guidance. What separates useful content standards from ignored ones is the presence of examples. People copy examples; they interpret principles.

Titles

A standard for titles should say what the title is for, how it is constructed and what to avoid, then show it. For instance:

• Rule: The SEO title describes the specific topic of the page in plain language, leads with the words a searcher would use, and does not repeat the same phrase across multiple pages.
• Weak example: "Services | Home | Brand" (says nothing about the page)
• Weak example: "Best Cheap Affordable Photo Editing Service Photo Editing Online" (repetitive, reads as spam)
• Strong example: "Product Photo Background Removal for Online Stores" (specific, readable, matches the page)

Note what the standard does not do: it does not invent a hard character limit presented as a search engine rule. Search engines truncate displayed titles based on available width, and they may rewrite titles they judge unhelpful. A practical standard can set an internal target, such as keeping the most important words near the start, and explain that the target is a house convention for readability rather than a ranking rule.

Headings

Specify one visible main heading per page that states the topic, followed by a logical sequence of subheadings that describe the sections beneath them. Give examples of headings that fail: "Overview," "More Info," "Why Us" as H2s on every service page tell neither readers nor search engines what the section contains. Show the rewrite: "How Background Removal Handles Hair and Fine Edges" is a heading a reader can scan and a search engine can understand.

Page structure

Write down the expected structure for each content type. A service page might require an opening paragraph that states what the service is and who it is for, a section on process, a section on deliverables and formats, and a section on turnaround and revisions. A how-to article might require the answer in the opening paragraphs, followed by steps. Structural templates reduce the number of decisions each writer has to make and keep the site consistent.

Internal linking

State how many contextual internal links a typical article should include, what anchor text should look like (descriptive of the destination, never "click here"), and which pages are priority destinations for each topic cluster. A short example helps more than a paragraph of guidance: "Link 'retouching standards for e-commerce' to the retouching service page; do not link the phrase 'learn more.'"

Descriptions and alternative text

Meta descriptions and image alternative text follow the same pattern: a one-sentence rule, a weak example, a strong example. For alternative text, add the rule for decorative images, which should typically have empty alternative text so screen readers skip them, and explain that alternative text describes the image rather than repeating the target keyword.

Writing Standards People Will Actually Follow

A standard is only as good as its readability. Many SEO documents fail not because the rules are wrong but because they are written for other SEO specialists: dense with jargon, long on theory, short on instructions. The people who need to follow the standards are writers and developers with other priorities, and the document has to respect their time.

Established technical writing guidance is a good model here. The Microsoft Writing Style Guide on Microsoft Learn advocates plain language, short sentences, direct instructions and consistent terminology, and those principles apply directly to internal standards. A few practical conventions follow from them:

• Lead with the instruction. Start each standard with what to do, in the imperative: "Set the canonical URL to the clean product URL." The explanation can follow.
• Explain why, briefly. One or two sentences on the reason helps people apply the rule sensibly in cases the standard did not anticipate.
• Make it testable. "Pages should be fast" is not a standard. "The product template's server response must include the product name, price and description text in the initial HTML" is, because someone can check it.
• Use consistent terms. Decide whether you say "SEO title," "title tag" or "title element," define it once, and use it everywhere. Inconsistent terminology creates the impression of separate rules.
• Keep each standard short. If a standard needs more than a screen of text, it probably contains several standards and should be split.

A template for a single standard

A consistent format makes standards faster to write, read and review. A workable template has seven fields:

Rule

One or two sentences in the imperative.

Applies to

The templates, components or content types covered.

Why

The search reason, with a link to the authoritative source.

Example

A correct implementation and, where useful, an incorrect one.

How to check

The test, tool or manual step that verifies compliance.

Owner

The named person responsible for keeping the standard current.

Last reviewed

The date and the reason for the most recent review.

The "How to check" field is the one teams most often leave blank, and it is the one that turns a guideline into a standard. If nobody can say how to verify a rule, nobody will verify it.

Review Points: Building Search Checks Into Launch

Standards need review points, and those review points must come before launch. Checks that happen only after launch are one of the mistakes most worth avoiding, because by the time a post-launch audit finds a problem, search engines may already have crawled and indexed the broken version, and the fix competes with every other post-launch priority.

Where the checks belong

Most organizations have at least two natural gates where search checks fit without adding a new process:

• Code review. Add a short SEO section to the pull request template for changes touching templates, routing, navigation or rendering. The reviewer confirms the change still meets the component's documented standards.
• Pre-launch sign-off. Add search items to the existing launch or release checklist: indexing directives correct for the environment, canonical tags pointing to production URLs, redirects in place, sitemap updated, structured data validating.

For content, the equivalent gate is the editorial review before publishing. The editor checks the content standards the same way they check spelling and brand voice: title follows the pattern, headings are descriptive, internal links point to the right destinations, alternative text is present.

Automate what you can, but not everything

Some checks are easy to automate: a test that fails the build if a staging "noindex" directive reaches production, a script that flags missing title elements or duplicate canonical targets across a crawl, a linter for heading order. Others need human judgment, such as whether a title actually describes the page. The standard should say which is which. Choosing the right crawler and monitoring tools for automated checks is its own decision; the guide to choosing SEO tools covers the trade-offs.

Redesigns and migrations are the highest-risk launches

The largest single regressions usually happen during redesigns and platform migrations, when many templates change at once and the people who built the old site may not be involved. Written standards give the new build team a specification to test against. Pair them with a migration plan such as the one described in protecting SEO in a redesign, and the standards become the acceptance criteria for the new templates.

Worked Example: Documenting Standards for a Mid-Sized Services Site

The following example is illustrative, not a client story. It shows how the process might run for a hypothetical services company with a site of roughly 1,200 indexable pages across 9 templates: home, service overview, service detail, industry page, article, article listing, case study, contact and location page. The company has one in-house SEO specialist, a content team of four and a development team of three.

Step one: inventory the existing knowledge

The specialist spends about two days collecting every search-related rule that exists today: old audit reports, closed tickets, Slack threads, the agency handover deck. In this illustrative case the inventory produces around 60 distinct rules, of which roughly a third are duplicates or out of date. That leaves about 40 rules worth keeping.

Step two: sort rules into layers and owners

The 40 rules are sorted into the four layers. Suppose 22 are technical and map to specific templates, 12 are content rules, and 6 are review or environment checks. Each technical rule is assigned to the template it governs; the service detail template alone might carry 7 rules, while the contact page carries 2. Each layer gets an owner: the lead developer for technical, the managing editor for content, the release manager for review points, and the SEO specialist for the index as a whole.

Step three: rewrite each rule in the standard format

Rewriting takes the longest. At an illustrative pace of 20 to 40 minutes per rule, including finding good and bad examples and writing the check, 40 rules take somewhere between 13 and 27 working hours. The range depends mainly on how many rules need new examples captured from the live site, and on how much discussion the owners need to agree on wording.

Step four: place the standards where the work happens

Technical rules move into the component documentation for each template. Content rules go into the editorial style guide, and the most important ones are copied into the help text of the CMS fields they govern, so a writer filling in the SEO title sees the rule and the example right beside the field. Review points are added to the pull request template and the launch checklist.

Step five: measure the effect

The company then tracks one simple indicator: how many search issues found in monthly crawls are regressions of previously fixed problems. Before documentation, the specialist estimates from memory that most recurring issues fall into this category. After six months, the team compares the regression count with the baseline. The point of the measurement is not a headline number; it is to find which standards are not working, usually because their check is missing or their placement is wrong.

For an organization running several sites, the same process applies, but the shared standards should live in one central place with site-specific exceptions documented per property. The briefing on managing SEO across multiple sites covers how to structure that split between shared rules and local variation.

Keeping Standards Current as Search Guidance Changes

Standards written once and forgotten are the second great failure mode, after knowledge held by one person. Search engines revise their documentation, deprecate features and change how they treat certain markup. Your own platform changes too: a new CMS field, a framework upgrade, a new template. A standard that was correct when written can become wrong without anyone noticing.

Triggers for review

Rather than relying only on a calendar, tie reviews to events:

• External guidance changes. When the search documentation a standard cites is updated, the owner of that standard reviews it. This is why each standard should link to its source.
• Platform changes. Any change to a template, the CMS schema or the rendering framework triggers a review of the standards attached to the affected components.
• Regressions. Every regression found in a crawl or audit prompts two questions: was there a standard, and if so, why did it not prevent this? The answer usually points to a missing check or a standard in the wrong place.
• Scheduled review. In addition to event triggers, a scheduled review, for example twice a year, catches drift. Each owner confirms their standards are still accurate and updates the "last reviewed" date.

Version control and change logs

Keep standards under version control or in a system with visible history. When a standard changes, record what changed and why in a short change log. That record serves two purposes: it helps people understand why the current rule exists, and it prevents a later team from reverting to an older rule that was deliberately replaced.

Retiring standards

Standards should also be removed when they no longer apply. A long list of obsolete rules erodes trust in the whole set. When a template is retired or a search feature is deprecated, archive the related standards with a note rather than leaving them in place.

Training and Onboarding Around the Standards

Documentation nobody is introduced to is documentation nobody reads. Training new team members on the standards is what turns a written set of rules into shared practice.

Role-specific onboarding

Do not train everyone on everything. A new writer needs a short walkthrough of the content standards, the CMS field help and the editorial checklist, perhaps 30 to 45 minutes with real examples from the site. A new developer needs to know where component documentation lives, which components carry SEO rules, and how the pull request checks work. A new product owner needs to understand the launch checklist and what blocks a release.

Teach the reasons, not only the rules

People follow rules they understand. A developer who knows why filter parameters must not create indexable URLs will make a sensible call on a new feature that the standard does not explicitly cover. A writer who understands that the title appears as the headline in search results will write better titles than one who is just following a pattern.

Make the specialist a reviewer of standards, not of every page

The long-term effect of good documentation is a change in the specialist's role. Instead of reviewing every page and ticket, they maintain the standards, review changes to them, investigate regressions and train people. That is a more valuable and more sustainable use of expertise, and it reduces the organization's exposure if the specialist moves on. It also makes it easier to set realistic expectations with leadership about what search work can deliver; the guide on setting SEO expectations covers that conversation.

Business Implications: Cost, Risk and When to Bring In Help

For executives, the case for documenting SEO standards comes down to three effects on the business.

Lower repeat cost

Every regression repeats the cost of diagnosing and fixing a problem the organization already paid to solve once. Standards placed where work happens, with checks before launch, cut that repeat cost. The investment is modest compared with most search projects: in the illustrative example above, a few weeks of part-time effort spread across existing staff.

Reduced key-person risk

When search quality depends on one specialist's memory, the organization carries a concentrated risk. A resignation, a long leave or an agency change can remove years of accumulated knowledge overnight. Written standards turn that knowledge into an organizational asset that persists through turnover.

Faster, safer releases

Clear, testable standards let development and content teams move faster, because they no longer need to wait for a specialist to review every change. They also make large launches safer, because the acceptance criteria for search are known before the build begins.

When to bring in help

The clearest signal is that search fixes keep regressing. If the same problems return after being fixed, and internal effort has not stopped them, the issue is usually the system rather than the individual fixes. Outside specialists can help in several ways: auditing the current state and identifying which rules are missing, writing technical standards for complex templates as part of technical SEO work, setting up review gates, and training teams. For organizations without a full-time specialist, an ongoing SEO retainer can cover maintenance of the standards and review of regressions over time.

When evaluating outside help for this work, ask to see an example of standards the provider has written for another organization, with details anonymized. Look for the characteristics described in this briefing: rules stored with components, examples for every content rule, a "how to check" for every standard, and named owners. The guide to choosing an SEO partner covers the broader selection criteria.

A practical starting point

If the full process feels large, start with the five rules that have regressed most often. Write each in the standard format, place it in the component or style guide where the relevant decision is made, add its check to the relevant gate, and assign an owner. That small set will prevent the most expensive repeat problems, and it establishes the format and habits that the rest of the standard set can grow from.

Where this comes from

• Google Search Central — Search Essentials
• Microsoft Learn — Microsoft Writing Style Guide

The figures and practices above come from the sources listed.

Working on something like this?

We take on SEO Services work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.

Where to go next

• Prioritizing Technical SEO Fixes: The Decisions That Matter
• Auditing an Inherited Site: The Decisions That Matter