Google has selected another URL for your service page
Imagine your commercial maintenance page is meant to appear at https://example.com/services/commercial-maintenance/. Search Console's indexed inspection instead names https://example.com/commercial-maintenance/ as the Google-selected canonical. Your marketing owner wants the service URL restored. Your developer needs to know whether there's a defect to repair.
This entire URL family is hypothetical. Every response, declaration and inspection result described below is an invented observation for the worked example. We haven't inspected a client property or measured a recovery.
A user-declared canonical expresses the site's preferred representative URL for duplicate or very similar content. The Google-selected canonical records Google's choice. Google's canonicalisation troubleshooting guidance recommends examining the selected page and whether it makes sense for visitors, then investigating technical signals and content differences.
Sometimes the selected URL is an acceptable representative and no change is needed. Sometimes a template points every duplicate at an obsolete address. Establish which situation you're in before asking someone to fix a canonical tag Google appears to have ignored.
Read the indexed evidence
Open indexed URL Inspection for the affected URL. Preserve the indexing reason, user-declared canonical, Google-selected canonical and last crawl. Inspect the selected URL too where your property access allows it. Record the intended destination separately, with the business reason for preferring it. That prevents a team preference from being mistaken for an observed Google result.
Google's Page indexing report documentation distinguishes several duplicate reasons. An accepted alternate correctly points to an indexed canonical and may need no action. A duplicate without a user-selected canonical has another URL chosen by Google despite no declared preference. When Google chooses a different canonical from the user, compare the inspected page, declared destination and selected destination. The status alone doesn't establish that the declaration is appropriate or that Google is wrong.
Save screenshots or exports with the capture time and timezone. Mark inaccessible selected-URL evidence as unavailable, especially when it belongs to another property. Keep assumptions about indexing or traffic out of the evidence record.
Use indexed inspection for canonical selection. Google's URL Inspection documentation explains that a live test can’t predict which URL will be canonical. A successful live fetch can support deployment checks while the indexed view still describes an earlier crawl. Keep both dates beside their evidence.
Compare the URLs before choosing a repair
Compare the main copy, service scope, audience, location relevance and purpose of each page. Open both as a prospective customer. Can someone obtain the same service information and take the same next step? Choose the representative URL by visitor purpose and consistent site signals.
In our hypothetical family, https://example.com/services/commercial-maintenance/?utm_source=newsletter contains the same service content as the clean service URL. If indexed inspection consolidates that tracking variant to the clean page and that's the intended outcome, record it as accepted. The tracking URL doesn't need its own indexed entry.
Now suppose the clean page declares the legacy https://example.com/commercial-maintenance/ address as canonical because an old template setting survives. The two pages describe the same offer, but the team intends to retain the clean service address. That supports a conflicting-signal investigation. Changing the template could be justified once the developer reproduces the output and confirms the business decision.
A genuinely different page needs another decision. If one page covers scheduled maintenance and another covers emergency repairs, their distinct buyer jobs may justify keeping both. Our practical recommendation is to decide which page should serve each search job, then make those differences clear in content and navigation. Shared keywords alone don't justify canonicalising one to the other.
The connection to Google Search and AI eligibility is limited. Google's requirements for AI feature supporting links require indexing and snippet eligibility, with no additional AI-only technical requirement. Resolving a canonical conflict can address a Search foundation. It doesn't promise an AI citation, ranking recovery or a particular URL's future selection.
Build the evidence sheet for the URL family
All entries below are hypothetical. “Clean” means /services/commercial-maintenance/, “tracking” adds ?utm_source=newsletter, and “legacy” means /commercial-maintenance/. Each uses https://example.com.
| Check | Evidence | Implication |
|---|---|---|
| Response | All three return 200 with equivalent copy | Available duplicates |
| Redirect | Legacy has none | Retirement is pending |
| Canonical | Clean and tracking declare legacy in HTML, with no HTTP canonical | Declarations favour legacy |
| Rendered output | Clean retains its legacy declaration | Rendering preserves the conflict |
| Sitemap | Includes clean and legacy | Mixed preference |
| Internal links | Service navigation points to legacy | Links favour legacy |
| Indexed choice | Clean inspection selects legacy | Google's choice follows legacy signals |
Alongside a real sheet, record the full origin, parameter string, environment, release identifier, tester and capture timestamp with timezone. Store each response or screenshot as linked evidence. Keep the indexed last crawl separate from the time you opened Search Console. A bare path in a spreadsheet is insufficient if several hosts or environments can serve it.
These hypothetical observations support investigating the template and navigation. The cause of Google's choice and each signal's weight remain unproven. If the initial HTML and rendered declaration differ, check canonical output after rendering and reproduce the change before assigning the repair.
Align the signals that the evidence implicates
Google's guidance on specifying a canonical URL describes redirects and canonical declarations as strong signals, with sitemap inclusion a weaker signal. Combining consistent methods supports the preference. Selection remains Google's decision.
For the hypothetical repair, the retained destination is https://example.com/services/commercial-maintenance/. Require that page to return a successful response, remain crawlable and permit indexing. Set its canonical declaration to that absolute URL. Correct the reproduced legacy template setting and check that HTML, HTTP headers and rendered output don't declare competing destinations.
The tracking variant remains available for campaign use and declares the clean service URL as canonical. The legacy equivalent is retired only after the owner confirms it serves the same visitor purpose and has no separate requirement to remain available. In this example, a permanent redirect sends https://example.com/commercial-maintenance/ directly to https://example.com/services/commercial-maintenance/.
Include the retained clean URL in the sitemap and remove the retired and tracking variants. Update service navigation and other affected internal links to the clean destination. Review the whole implicated template so the same setting doesn't continue producing contradictory declarations elsewhere.
Google's same implementation guidance advises against using robots.txt for canonicalisation or using noindex to influence canonical selection within a site. Blocking a duplicate can prevent Google from reading its declaration. Removing it from Search is a separate publishing decision. Keep deliberate access and exclusion policies with their owners rather than changing them as a consolidation shortcut.
Give the developer a repair brief with pass conditions
Give the developer a reproducible finding, an agreed destination and clear pass conditions. Attach the evidence sheet.
- Name the affected URLs, shared template and intended canonical, with the owner's reason for retaining it.
- Link the captures and record their environment, timestamps, indexed crawl dates and unavailable evidence.
- Describe the reproduced cause and exact change, including declarations, redirect destination, sitemap entries and internal links.
- Assign a developer, release identifier and marketing verification owner. Set a review date and timezone.
- Name an unaffected template control and its expected canonical, so the repair can be checked for unintended effects.
- State deployed pass conditions separately from the pending indexed outcome.
For the hypothetical brief, assign the website developer to correct the shared canonical setting and navigation. The clean page and retained tracking variant must declare https://example.com/services/commercial-maintenance/. The legacy address must redirect directly there. The sitemap and service navigation must use the clean address. A control such as https://example.com/services/emergency-repairs/ must retain its own declaration and working response. These are example acceptance conditions, not verified site results.
When conflicting signals span templates and the cause remains unresolved, scope the unresolved canonical diagnosis before commissioning a broad change. When reproduction confirms a shared defect, the brief can support work to repair the affected website templates.
Verify the release and return to indexed inspection
Deployment correctness, live-test evidence and Google's indexed selection need separate entries in the repair record. Google's indexed and live inspection guidance supports that separation. A passing current test can't turn an older indexed result into evidence about the new release.
- Recheck deployed response codes, redirect destinations, canonical declarations, sitemap entries and internal links for the affected family and control URL. Save captures against the release identifier and time.
- Run appropriate live URL Inspection tests and preserve the results independently. Record any fetch or rendering failures and resolve them before describing the deployment as passed.
- Request indexing for important repaired URLs where appropriate. Google's canonical troubleshooting sequence includes re-indexing requests after fixes. A request doesn't establish when reprocessing will occur.
- Return to indexed inspection for the affected and intended URLs after reprocessing. Record the reported last crawl, indexing reason and Google-selected canonical. Compare that evidence with the release time.
- Keep the indexed outcome pending if the available evidence predates the release. Assign an owner and a dated next review. If fresh post-release evidence still selects an unexpected URL, reopen the content and technical hypothesis with the new captures.
For the hypothetical handoff, the marketing owner could schedule an indexed review for 14 November 2026 in Australia/Perth. That's an administrative checkpoint, not a promised recrawl deadline. If the evidence is still old, the owner records the pending state and assigns another review.
Close the selection issue only when the available indexed evidence supports the intended outcome, or when the owner accepts Google's alternative as legitimate.