How we detected and retired orphan SEO variants

On 27 July 2026, we retired the search-intent URL variants from PriviTools tool pages. This was not a response to a Google penalty or a Search Console warning. It was the result of auditing our static implementation.

The first version of this post used an aggregate page count that could not be reconciled with all of the build tables. We removed it. A useful post-mortem must let readers reconstruct its premises; if a number cannot be reproduced from the commit and its build artifact, it does not belong in the headline.

What the historic code does verify is the design issue: every base tool page had four URL variants for “free”, “fast”, “Mac”, and “Windows”. Each tool was therefore built five times. The current version keeps those arguments as sections of one canonical page instead of separate URLs.

The idea: one URL for every search nuance

The intuition was simple. Someone may search for “compress PDF”, “compress PDF free”, or “compress PDF for Mac”. We created a route for each phrasing:

/en/tools/compress-pdf/
/en/tools/compress-pdf-free/
/en/tools/compress-pdf-fast/
/en/tools/compress-pdf-mac/
/en/tools/compress-pdf-windows/

The generator iterated over each localized tool and applied five modifiers. Variant pages had extra copy, but they performed the same task and delivered the same result as the base page.

To avoid competing with the base page, the four variants emitted a canonical URL pointing back to it. That was already an architectural warning: if a URL needs to tell search engines that another URL is the main representation, it is worth asking why the separate page exists.

What the audit found

We inspected the generator, sitemap, and built-site links. Three facts made consolidation the right move:

1. No contextual internal links. Navigation, category hubs, and tool pages linked to the base URL rather than a variant.
2. No sitemap entries. The sitemap generator excluded canonicalized routes so it would not present duplicates as priority pages.
3. A canonical pointing elsewhere. Even if a crawler reached a variant from an external source, the page itself nominated the base page as its representative.

It would be inaccurate to say a search engine can never discover a URL without the first two paths: it can learn about it from external links, historic URLs, or other signals. It is accurate to say our product did not provide an internal, systematic, or consistent discovery path. Google explains that comprehensive linking and a sitemap help discovery, but do not guarantee crawling or indexing. Read Google’s sitemap documentation.

Why a canonical did not fix the architecture

A canonical is a signal for consolidating representations; it does not turn five light variations into five independently valuable documents. In this case, one page could answer questions about price, speed, and compatibility with a coherent experience and one URL to link to, measure, and maintain.

We also avoided normalizing the creation of near-identical pages merely to repeat a keyword. Google’s spam policies flag pages designed to lead similar searches to the same destination when they do not provide unique value. See the policy.

The change: consolidate the content, not delete it

We did not throw away the explanations of compatibility, free access, or local processing. We moved them into editorial blocks on the base tool page. A visitor can still find the relevant information without going through a parallel route.

The rule now lives in code and in a test: getSeoPaths generates one URL per tool and language. If a slug modifier is added again, the test fails. That makes the decision observable and maintainable instead of dependent on someone remembering a meeting.

How to repeat the audit

Looking at a rendered page is not enough to audit programmatic SEO. Inspect the static artifact and ask:

• Does every important URL appear in a sitemap or have sufficient internal links?
• Does the content justify its own canonical URL?
• Are the differences between routes substantial, or only a modifier?
• How many routes, tests, and template changes multiply with every new variant?
• Is there a test that prevents the pattern from returning?

When the answers show that routes compete with one another, consolidation is usually more honest and more maintainable than adding more copy to every URL. The PriviTools tool index shows the resulting base-page approach.

What we will measure next

This article was updated on 28 July 2026. We will publish follow-ups only once comparable data exists: Search Console coverage and indexing, impressions, clicks, and observed crawl changes. We will not pre-announce 7-, 14-, or 30-day outcomes as evidence before they exist.