A design team ships continuously and a search review is a queue. Put every change through it and people learn to route around it; put none through and a rebuild eventually removes something that was earning money, which nobody notices for two months.
The useful version of this policy is short, and it does not depend on anyone on the design side knowing much about search.
Which design changes actually carry search risk?
Three kinds: changes to what is in the HTML, changes to where links point, and changes to what a page claims about itself. Everything else is visual, and visual changes are safe.
That is the whole test, and it is answerable from a wireframe. A designer does not have to judge the search consequence — they have to notice that a block of text is gone, a link is gone, or a byline is gone, and send that one screen for a look.
Why is "it looks the same" not the test?
Because search engines read the document, not the design, and the two can diverge in either direction. A page can look identical and be built from completely different markup.
The common version: a rebuild reproduces the visual hierarchy with styled containers instead of headings. Nothing changes on screen, and the structure a search engine uses to work out what the page covers has been flattened into undifferentiated text. The reverse also happens — a page that looks dramatically different but ships the same content in the same order is usually fine.
So "does it look the same" is the wrong question and "is the same content still in the HTML, in the same order, with the same links out of it" is the right one.
Does hiding content in tabs or accordions hurt?
Not if the content is in the HTML when the page loads. It hurts when the click is what fetches it.
Collapsed content that is present in the markup and hidden with CSS is indexable, and folding a long page into accordions is usually a genuine user experience improvement on a phone. Content that is requested from an endpoint when a tab is clicked may never be seen, because a crawler does not click tabs.
The review question is one line to a developer: is the panel content in the initial HTML, or loaded on interaction? The visual design is identical either way, which is exactly why this one gets missed.
The risky changes are the ones that are invisible in the comparison screenshot. If the before and after look the same, nobody reviews it — which is why markup-level rewrites do more damage than dramatic visual redesigns.
Which navigation changes cost the most?
Any change that removes links, because navigation links are site-wide and they are how importance gets distributed internally.
Simplifying a menu from thirty items to eight is a real improvement for visitors and a real demotion for twenty-two sections, which lose the only link they had from every page on the site. The same applies to a footer trimmed for tidiness and to a category page that drops its child links in favor of a search box.
This is not an argument against simplifying. It is an argument for deciding where the removed links are going to live instead — a hub page, a related section, a contextual link from the parent — before the menu ships rather than after the rankings move.
What does a redesign drop without noticing?
The furniture around the content, which is also most of what a page uses to establish who is talking and what it is.
Bylines and publication dates go first, because they clutter a clean article template. Both are part of how a page demonstrates E-E-A-T, and both are cheap to keep. Customer reviews get moved into a modal, which removes the user-generated content from the page and usually breaks the markup that described it. Breadcrumbs get replaced with a back arrow, taking a navigational path and its structured data with them.
None of these are design mistakes on their own terms. They are all removals that nobody costed, because the thing removed was not what the redesign was about.
Which changes can ship with no review at all?
Anything that changes appearance without changing content, links, or markup structure. That is most design work, and saying so out loud is what makes the rest of the policy credible.
- Color, type, spacing, and imagery changes.
- Component restyling that keeps the same elements.
- Motion and interaction polish on content already present.
- Form layout and field styling, as long as the submitted result is the same.
- Anything behind a login, which search engines never see.
Where should the review actually sit?
At the wireframe, not at the pull request. By the time a change is in code, the cost of restructuring it is high enough that the review turns into a negotiation.
| Change | Review needed? | What to check |
|---|---|---|
| Restyling an existing component | No | — |
| Tabs or accordions over existing copy | Yes | Content present in initial HTML |
| Removing or consolidating nav links | Yes | Where the lost links are replaced |
| Any URL change | Yes | Redirect map before launch |
| Removing bylines, dates, or reviews | Yes | What the page loses that it was credited for |
| Replacing headings with styled text | Yes | Heading levels survive the rebuild |
| Infinite scroll replacing pagination | Yes | Crawlable links to every item remain |
| New imagery or illustration | No | — |
Running the review as a launch gate instead of a wireframe check. A veto a week before release does not protect the site — it gets overruled, and then the same problems get fixed under pressure after traffic falls.
How do you make the review cheap enough to survive?
Make the trigger something a designer can spot without search knowledge. Three questions on the ticket template will catch nearly everything worth catching.
- Does any text or link that exists today disappear on this screen?
- Does any URL change?
- Is anything on this screen loaded after a click rather than on load?
A no to all three means ship it. Any yes means one person looks at one screen for ten minutes, which is a cost a team will actually pay — unlike a mandatory review of everything, which gets abandoned within a quarter and takes the real cases with it.
Look at what is in your design queue right now and run those three questions over it. Whatever comes back with a yes is the work that needed a conversation, and the fact that it is probably one or two tickets out of a dozen is the point — page experience work and search safety are not in conflict often, and knowing exactly when they are is what lets you stop treating every change as though they were.
Redesign coming and nobody has checked what it costs in search?
We will review the wireframes against what your pages currently earn and flag the changes that need a plan before they reach a developer.
Get in Touch →Does this apply to your site?
Reading about it is one thing. Point the scan at your own site and see whether this applies to you, and what it is worth fixing.
Free and unlimited. No account, no card, and you get every finding rather than a teaser.