How to fix the duplicate pages your CMS created for you
Identify the duplicate URLs your website platform generates automatically and understand how each type is resolved without losing pages.
Pages nobody wrote
A business with forty written pages looks at Search Console and finds nine hundred URLs. Nobody created them. The content management system did, through tag archives, author pages, filter combinations, pagination and session parameters. Each one is a page as far as a crawler is concerned.
The effect is dilution rather than penalty. A crawler spends its allocation on near identical URLs instead of your service pages, and when several of your URLs carry the same content the search engine picks one to show. It often picks the wrong one. Customers then land on a tag archive instead of the page with the enquiry form.
What repair costs and what it excludes
This work excludes content improvement. Resolving duplicates makes the right pages visible. It does not make them better, and a site with weak service pages will simply have weak pages that are correctly indexed. Budget content separately.
The cost depends almost entirely on the platform. WordPress with a well maintained SEO plugin handles most of this through settings. A custom build or a heavily filtered ecommerce catalogue needs developer time, which is the real line item. A diagnosis is available as a technical SEO audit with the scope and rate published on that page, and implementation sits with whoever maintains the site. Fees carry GST at 18%.
Who should do this now, and who can ignore it
Do it now if your site has a filtered catalogue, a blog with years of tagging, multiple language or city variants, or a migration in its history. Ecommerce sites with faceted navigation are the clearest case. Do it also if Search Console reports far more discovered URLs than you have pages, or reports pages as duplicate without a chosen canonical.
Ignore it if you run a brochure site of under thirty pages with no filters, no tags and no parameters. The duplicates do not exist in any volume that matters and the work will change nothing you can measure. A business in that position is being sold a technical audit for a problem it does not have, and the budget belongs on its service pages instead. Ignore it also if you are about to rebuild the site, since the rebuild decides the URL structure anyway.
How each type is resolved
Start by finding them. Search Console's page indexing report lists URLs excluded as duplicates and names which URL the search engine chose instead. That report alone identifies most of the problem. Group what you find by cause rather than by URL, since each cause has one fix.
Content that genuinely exists at several addresses is resolved with a canonical tag naming the preferred address, which tells search engines to consolidate signals onto it while leaving the other version reachable. Pages that should no longer exist at all are resolved with a permanent redirect to the nearest equivalent, never to the homepage. Thin generated archives such as tag pages, author pages and date archives are either switched off in the platform settings or marked not to be indexed.
Parameter and filter URLs are the hardest group. The usual approach is to canonicalise filtered variants back to the unfiltered category, and allow indexing only for the few filter combinations that have genuine search demand. Then fix how the site links to itself. If your navigation and sitemap point at the versions you have just demoted then the signals continue to conflict.
How to tell whether it worked
The metric that matters is the ratio of indexed pages to pages you actually wrote, moving towards one. Pair it with whether the correct URL now appears for your main commercial queries. Check by searching the phrase and seeing which of your pages is shown.
The metric that flatters is the raw count of indexed pages. Owners often read a falling count as damage when it is the intended result. Read the composition of the count rather than the count, and expect several weeks of churn before it settles, because recrawling happens on the search engine's schedule and not yours.
The common mistake
The expensive error is blocking duplicates in the robots file. It feels like the direct solution and it does the opposite. A blocked URL cannot be crawled, so the canonical tag or the noindex instruction on it is never read, and the URL can remain in results as a bare link with no description. The duplicate is now both present and uncorrectable.
The second error is pointing every canonical tag at the homepage, or redirecting every retired URL there. Both discard the relevance those pages had. A retired product page should redirect to its category or its replacement. A page with no equivalent should return a not found status and be left to drop out.
Before touching anything
Take a full list of current URLs and their indexed status before making changes, because redirects applied in bulk are hard to unwind without one. Make the changes in groups and wait a fortnight between groups so cause and effect stay legible. Anyone implementing this on a live store should have a developer confirm the behaviour on a staging copy first.
Nobody can promise a ranking improvement from this work. What it does is remove a self inflicted obstacle, which is a more honest claim.
This guide explains how something works. It is not legal, tax or financial advice, and rules change. Confirm anything regulatory with a qualified professional before you act on it.