Most SEO changes can be made quickly and safely: a better title, an extra internal link, a clearer heading. A few cannot. They are changes where a single mistake in one release can affect every page on a site, and where the damage can take weeks to find and longer to repair. Those changes deserve a different process from the rest, one that names who approves them and how they are undone.
The changes that carry site-wide risk
Robots.txt rules
A robots.txt file tells crawlers which URLs they may access. Google’s introduction describes it as being used mainly to avoid overloading a site with requests, and says that it is not a mechanism for keeping a web page out of Google
. Because it controls access across a whole site from one short file, a misplaced rule can stop crawling of a section, or everything. Changes to it should be reviewed line by line and tested before they go live.
Noindex and other index controls
Google’s traffic-drop guide uses a misplaced noindex tag as its example of a page-wide technical issue. A noindex that reaches a shared template reaches every page that uses it. Any change to robots meta tags or headers in a template needs a check of what the affected pages will send.
Canonical logic
Google explains that it groups duplicate pages and picks one canonical version to show. Changing how canonical tags are generated can move large numbers of pages from “indexed” to “treated as a duplicate” without any visible change on the pages themselves. Review the rules and test a sample from each template.
Redirects and URL structure
Changing URLs is the most disruptive thing most sites do. Google’s site-move guidance recommends mapping old URLs to their new destinations in complex moves, and, where possible, moving part of a site first to test the effects. Redirect rules need review, a test against a full list of old URLs, and an agreed plan for what happens after launch.
Template-wide changes
Changes to titles, headings, navigation, internal linking blocks and structured data in shared templates apply to every page that uses the template. The size of the audience is the risk, even when each individual change is small.
International and migration settings
Hreflang, domain changes, hosting moves and platform migrations belong in the same category. They combine several of the risks above and should be planned as projects, not as tasks.
What a sign-off needs to contain
- What is changing, in plain terms, and where it applies.
- Why, and what outcome is expected.
- The evidence and the test: what was checked before release, on which pages.
- The risk, and what the worst realistic outcome would be.
- The rollback plan: how the change is undone, how long that takes, and who can do it.
- The approver, a named person with the authority to say yes.
- The after-check: what will be checked after release, and when.
What to test, by type of change
- Robots.txt: fetch the new file and check a sample of important URLs, and a sample that should be blocked, against it. Search Console’s robots.txt report shows which files Google has found, so confirm Google is reading the version you expect.
- Noindex: check both the robots meta tag in the page source and the
X-Robots-Tagresponse header, which Google’s documentation covers, on a sample from every template. - Canonicals: compare the canonical tag on a sample of pages with what URL Inspection reports as the page’s canonical, and confirm each page declares itself where it should.
- Redirects: request every old URL, or a large and representative sample, and check that each returns the right status code and lands on the right destination in one step.
- Templates: render at least one page from every template affected, and compare titles, headings, links and structured data with the version before.
Who should approve
The approver should be someone who understands the consequences and can authorise the change: typically a head of digital, a product or engineering lead, or the site owner, depending on the organisation. It should not be the person making the change, and it should not be an executive who has never seen the details. In a small organisation, one person may wear every hat. Even then, writing down the change, the risk and the rollback before releasing is valuable, because it forces a pause at the moment the pause is cheapest.
Record the decision, not just the conversation
A sign-off that exists only in a chat thread or in someone’s memory is hard to rely on a year later. Record what was approved, which version of the plan or document it related to, who approved it and when. That record protects everyone: it shows the client what they agreed to, and shows the consultant what was and was not approved. It also makes it far easier to investigate a drop in traffic, because the change log and the approvals together show what changed and who decided it. This is the same reasoning as keeping approvals as recorded decisions, and SEO Ops records them that way.
Before and after
For each risky change, capture a baseline first: which URLs are indexed, what the crawl stats look like, which pages receive the traffic. After release, compare. If something has gone wrong, you want to find it from your own checks within hours, not from a client message a fortnight later.
After release: a watch window
Approval does not end at release. Agree a short watch window, a few days for most changes and longer for migrations, during which someone looks at the agreed checks each day: indexed page counts, crawl errors, the status of sample URLs, and the traffic to the affected section. If a measure moves the wrong way, the rollback plan is already written and the person who can execute it already knows. A problem found on the second day costs a fraction of one found in the second week.
Everything else can move fast
The point of keeping this list short is to protect speed. Most work should flow without ceremony. When the process is reserved for the changes that can hurt, people take it seriously, and when everything needs sign-off, nothing gets it properly.