Search Console says “Duplicate, Google chose different canonical than user”, and a service page you want customers to find is not indexed separately. Before changing anything, find out which page Google selected and whether that choice actually sends people to the wrong content.
The same message can describe a harmless duplicate address or a valuable page being grouped with something else. The right response depends on the customer journey, the content and the technical signals your website sends.
What does Google choosing a different canonical mean?
A canonical is the representative URL Google chooses from pages it considers duplicates or very similar. Your website can suggest a preferred address, but that suggestion does not compel Google to select it. Google’s explanation of canonicalisation also makes clear that some duplicate content is normal and does not, by itself, breach its spam policies.
For example, one service description might be accessible at a clean address and a second address containing campaign parameters. You would normally want one representative result for that content. Two genuinely different services need a different investigation.
This is also separate from a page ranking below another page for a particular search. If both pages are indexed with their intended canonicals, a different page appearing higher does not establish a canonicalisation fault.
Start with the three addresses in Search Console
Open the affected URL in Search Console’s URL Inspection tool and expand its indexing information. Record:
- The inspected URL: the exact address you expected Google to index.
- The user-declared canonical: the address your website suggested, if one is reported.
- The Google-selected canonical: the address Google actually chose.
These may be two different addresses or three. Open each in a browser and compare the main content, not just the page title. Google’s Page indexing guidance specifically recommends comparing these pages when investigating this status.
Use the indexed information for Google’s selection. The URL Inspection documentation explains that the live test cannot predict which URL will be canonical. A successful live test therefore does not establish that Google has accepted your preferred address.
Record the last crawl date alongside your checks. A page repaired this morning and an indexed report based on an earlier crawl describe different moments. Keep that distinction visible when briefing your developer.
Decide what customers should reach
Write one sentence explaining the intended outcome before requesting a technical change. For example: “Customers searching for emergency repairs should reach the emergency repair page, while planned servicing has its own page.” This gives the investigation a commercial purpose.
If the pages are genuine duplicates
Choose the address you want to maintain and promote. Consider the existing navigation, customer bookmarks, printed materials and integrations before renaming anything. A shorter address alone is a weak reason to disrupt a working journey.
If Google’s choice is already the useful public page, you may only need to tidy inconsistent signals. An excluded duplicate does not need to become a separate search result merely to reduce a report count.
If the pages serve different needs
Compare what each page helps a customer decide. For our repair and servicing example, useful differences might include the work covered, appointment process, exclusions and preparation required.
Ask someone who handles enquiries to review both pages. Can they explain why a customer needs one rather than the other? If the answer depends on information absent from the page, that is a useful content brief. Avoid rewriting sentences solely to make the wording different.
Check for conflicting technical signals
Ask your developer to review the affected pages together. Google’s canonical specification guidance describes redirects and canonical annotations as strong signals, with sitemap inclusion a weaker signal. It also recommends linking internally to the preferred canonical URL.
Check these elements as one set:
- The canonical address emitted in the page’s HTML head or HTTP response header.
- The final destination after any redirects.
- The address listed in the sitemap.
- The destination of relevant navigation and in-content links.
Agree one preferred address for equivalent content. Use an absolute canonical URL, including the correct hostname and HTTPS scheme, and give the preferred page its own self-referencing canonical. Avoid different destinations in different canonical methods.
Request a comparison of one affected page and one unaffected page using the same template. That can help the maintainer distinguish a single page override from a shared configuration problem without making speculative site-wide changes.
Find the component producing the wrong address
Google’s canonicalisation troubleshooting guide identifies incorrect CMS or plugin output and server misconfiguration as possible causes. It also notes that injected cross-domain canonicals or redirects can occur on compromised websites.
Have the maintainer identify where the observed value originates: a page setting, shared template, plugin, server rule or another integration. Do not add a second canonical simply to counteract the first one. Repair the source of the incorrect output and check other pages that use it.
An unfamiliar external destination warrants prompt investigation. Preserve the affected URLs and response evidence rather than assuming it is ordinary duplicate content.
If the saved setting looks correct but the public response remains old, follow our guide to website changes not showing. Verify the actual public output before requesting another Google crawl.
When both pages matter, make their purpose clear
Google’s troubleshooting guidance also stresses that pages grouped together need sufficiently different content if they are to be treated separately. A canonical setting cannot substitute for that distinction.
Build the revision around questions customers actually ask. For a service page, that could mean explaining suitability, what the work includes, practical limitations and the next step. Use relevant photographs or examples only when they are accurate and you have permission to publish them.
Do not manufacture separate town pages by swapping place names in otherwise identical copy. If your service works the same way everywhere, consider whether one useful coverage page would serve customers better. A separate location page deserves information that genuinely helps somebody in that location.
Ask the content owner to approve the factual differences before the developer implements them. Keep a record of what changed so the later review can assess the intended distinction rather than just the presence of a canonical tag.
Use a redirect when the duplicate is being retired
If an equivalent old page no longer needs to remain available, a permanent redirect may be the appropriate outcome. Google’s redirect guidance recommends permanent server-side redirects where possible for a permanent URL move; HTTP 301 and 308 represent permanent moves.
A canonical annotation does not move a visitor to another page. A redirect does. Choose between them according to whether people still need access to both addresses.
Before retiring an address, list where it is used: adverts, navigation, customer emails, booking links and external integrations. Test that those routes still reach the relevant destination and that customers can complete the enquiry or purchase.
Avoid directing unrelated service pages to the homepage as a blanket cleanup. First decide whether each page is a duplicate, a distinct service or content being removed.
Do not hide the page to force the choice
Google’s canonical specification guidance advises against using robots.txt or the URL removal tool for canonicalisation. It also recommends canonical annotations rather than noindex for choosing between pages within one website: noindex blocks a page from Search.
If your aim is for a valuable page to appear, hiding it is the wrong outcome. Keep access controls, removal decisions and duplicate consolidation tied to their actual purposes.
Verify the repair in two stages
First, ask for evidence from the live website. Confirm the intended content appears, the canonical output is correct, redirects behave as agreed and customers can complete the relevant journey. Use a live inspection to check what Google can currently access, while remembering that it cannot confirm the eventual canonical choice.
Then monitor the indexed result. For a small number of important changed URLs, use Search Console’s indexing request facility. Google’s recrawl guidance says crawling can take days to weeks, repeated requests do not accelerate it, and a request does not guarantee inclusion. For many changed URLs, use a sitemap.
When the reported crawl date moves beyond the repair, compare the selected canonical again. For genuine duplicates, success may mean the preferred page represents the group while alternatives remain excluded. For distinct pages, check each intended URL separately.
Agree who will review the result and what evidence would trigger further work. A useful handover includes the affected addresses, intended outcome, confirmed cause, repair date and follow-up check.
If an important service page is being grouped with the wrong content, talk to BuzzBoost about checking the technical signals and page purpose together. Our SEO work includes technical foundations and content planning, so the repair can support the route customers actually need.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
