Technical SEO

Canonical vs noindex: which to use?

A decision-led guide to choosing canonical, noindex or a redirect without giving search engines conflicting signals.

Published 11 August 2026Updated 12 August 2026

Canonical vs noindex decisions become clearer when you separate three questions:

Should the URL still open for visitors?
Should it appear in search?
Does it repeat another page?

A tracking URL may need to keep working without competing with the clean product page. A form confirmation page may need to open for customers without appearing on Google. An old service page may need to send everyone to its replacement. Those pages need different treatments because a canonical tag, a noindex instruction and a redirect don’t do the same job.

Starting with the result you want prevents a technical setting from hiding the wrong page or sending visitors somewhere unhelpful.

The practical rule is:

Decide what should happen to the page, then choose the signal that describes that outcome.

Canonical and noindex solve different problems

What is a canonical tag?

A canonical tag is a line in a page’s code that names the version you want search engines to treat as the main one. For example, example.com/shoes?utm_source=email might repeat the same product as example.com/shoes. The tracking URL can name the clean product URL as its canonical. Both addresses still open for visitors, while the canonical tag asks search engines to group them and show the clean address in results.

What is a noindex tag?

Noindex is a separate instruction in the page’s code that tells a search engine not to show that page in its results. The page still opens for anyone who visits the URL, but noindex neither identifies a replacement page nor sends visitors elsewhere.

Signal	What visitors experience	What you ask search engines to do	Best fit
Canonical	The page still opens normally.	Treat another duplicate or very similar URL as the preferred version.	Tracking URLs, print versions and close page variants that must remain available.
`noindex`	The page still opens normally.	Keep this page out of search results.	Utility, account, campaign or internal pages with no useful search role.
Permanent redirect	Visitors are sent to another URL.	Treat the destination as the new permanent location.	Replaced, merged or moved pages that no longer need a separate experience.

If you haven’t decided what the page should do, neither tag can make that decision for you. First, write down whether the URL should keep working. Then decide whether it deserves its own search result. Finally, check whether another page already serves the same need. The answers point to the safer option.

Match the page outcome to the signal

Work through the questions in order. They turn a tag debate into a page decision that anyone responsible for the website can check.

1. Should this URL keep serving visitors?

If the URL shouldn’t keep serving visitors, a permanent redirect is usually clearer. Leaving the old page live with a canonical or noindex tag doesn’t move the visitor. A redirect automatically takes anyone who requests the old URL to a new one, changing the visitor’s journey as well as the search signal.

Google describes permanent redirects as a strong signal that the destination should become the preferred URL. Its redirect guidance recommends a server-side permanent redirect when a page has moved for good. This usually means an HTTP 301 or 308 response.

Only redirect to a page that fully replaces the old one. Sending every removed product or service URL to the homepage creates a poor experience and may also be treated as a soft 404. The server response looks successful, but the requested content isn’t there.

If the page has gone, check whether a useful replacement exists. When it doesn’t, a 404 or 410 response may be more honest than any option in the table.

2. If the page stays live, should it appear as its own search result?

If yes, the page normally needs a self-referencing canonical. That means the canonical tag names the same URL the visitor has opened. It confirms that this page, rather than an alternate copy, is the version you want search engines to show.

If it shouldn’t appear on its own, ask why. The reason separates the two choices.

3. Is it duplicate or very similar to a preferred page?

Use a canonical when the answer is yes and the alternate URL still has a reason to exist for visitors or site functions.

Google’s canonical documentation says canonical tags apply to duplicate or very similar pages. It also explains that Google may combine signals from alternate versions, such as links pointing to them, around the URL it selects as canonical.

The pages must genuinely repeat the same content or serve almost the same purpose. A canonical tag isn’t a way to transfer the search value of any unwanted page to a stronger one. If two pages answer different customer needs, Google may ignore the tag, choose another canonical URL or keep both pages separate.

4. Must it stay live without appearing in search?

Use noindex when the page has a useful job on the website but no role as a search result. It also shouldn’t be an alternate copy of another page. A checkout step is a familiar example. Customers need it to complete an order, but somebody landing there from Google couldn’t start the journey properly.

Google defines noindex as an instruction not to show a page, media item or file in search results. Its robots meta guidance adds one important condition: Google’s crawler must be allowed to visit the URL before it can read the instruction.

Bing gives the same warning in its robots meta guide. Don’t block a noindex page in robots.txt, the file that controls which URLs search crawlers may visit. If the crawler is blocked, the search engine may never see the noindex instruction on the page.

When a canonical is the better choice

A canonical fits when several URLs present the same core page and one should be the version shown in search. Common examples include:

a product page with tracking parameters added to the URL;
printable and standard versions of the same guide;
the same document offered as HTML and PDF, using an HTTP canonical header where needed;
close product variants that don’t give searchers meaningfully different choices;
syndication arrangements where the republished version names the original source as preferred.

In cases like these, the alternate URL remains open to visitors and search crawlers. Bear in mind, though, that search engines still make the final choice, so a canonical tag acts as a strong request rather than a command they must follow.

Keep the rest of the site consistent with that request. Links within your website should point to the preferred URL. Your XML sitemap should include the preferred version too. This sitemap lists the URLs you want search engines to discover. Avoid naming one URL in the canonical tag while your links and sitemap favour another.

Google specifically recommends rel="canonical" rather than noindex when you need to choose one version within the same site. That is the clearest dividing line between grouping duplicate pages and excluding a page from search.

When noindex is the better choice

Noindex fits pages that need to work but don’t deserve a place in public search results. Examples may include:

account, basket or checkout steps;
form confirmation pages;
internal search-result pages;
short-lived campaign pages with no organic search purpose;
utility pages that support a journey but don’t answer a search need;
test pages that are protected from public access and also carry a defensive noindex rule.

Noindex isn’t a privacy control. The page can still be opened by anyone who knows its URL unless a login, password or another access rule protects it.

Search engines also need time to crawl the page and process the instruction. A URL may continue to appear briefly after noindex is added, especially if crawling is infrequent.

If Google Search Console reports an unexpected indexing state, use the crawled but not indexed checks before changing tags. The report may describe an earlier version of the page. The live code may have changed since Google’s last visit. Google may also have picked a different canonical URL.

Why using canonical and noindex together is a poor default

The two settings describe different outcomes. A canonical asks a search engine to group this page with another URL and show one version in search. Noindex asks the search engine to remove this page from results altogether.

Search engines may find both instructions on the same page, but using them together creates two different outcomes to explain and maintain. Google recommends rel="canonical", not noindex, when the task is choosing a preferred URL. One instruction that matches the result you want is easier to test, explain and keep consistent.

If a crawl finds both settings, don’t remove one at random. Ask which of these statements is true:

This page is an alternate version that should support a preferred URL.
This page must stay live but should have no search result of its own.
This page has moved and visitors should reach its replacement instead.

The first points to rel="canonical", the second to noindex and the third to a permanent redirect.

Common page types and the safer starting point

Page situation	Safer starting point	Why
Tracking parameter creates another URL for the same page	Canonical	The alternate remains usable but the clean URL should represent it.
Printer-friendly copy repeats the article	Canonical	Both versions serve users, although only one needs to be preferred in search.
Internal search results have no stable search value	`noindex`	The page must work on the site but shouldn’t become a public result.
Campaign page must stay available to advert visitors only	`noindex`	It has a live journey but no intended organic role.
Old service page has a direct replacement	Permanent redirect	Users and search engines should reach the replacement.
Removed page has no relevant replacement	`404` or `410`	There is no honest destination or preferred duplicate.
Two pages target different customer needs	Keep both indexable	The tag would hide a real difference instead of resolving duplication.

These are starting points, not automatic rules. Filtered category pages, product variants and regional pages can look similar while serving different searches. Review the actual page purpose before applying one rule across the site.

Check the implementation before asking for a recrawl

Opening the page in a browser isn’t enough because the important instructions sit in the server response or page code. Record the final URL after any redirect and the HTTP status code that describes the server’s response. Then record the noindex rule and the canonical URL found in the source HTML or HTTP headers.

For a canonical setup, confirm that:

the alternate and preferred pages are duplicate or very similar;
the tag uses an absolute, indexable URL;
the preferred page points to itself;
internal links and the sitemap favour the preferred URL;
redirects, tags and sitemap entries don’t name different destinations.

For a noindex decision, confirm that:

the URL returns the intended live page;
the rule appears in a robots meta tag or X-Robots-Tag header;
robots.txt doesn’t prevent search crawlers from reading it;
the page doesn’t contain information that needs authentication rather than search exclusion;
templates haven’t added the rule to pages that should remain searchable.

For a redirect, confirm that the old URL reaches the intended replacement directly. A chain sends the visitor through several URLs before the destination, while a loop sends them around without ever reaching a working page. If the change is part of a larger move, follow the site migration monitoring sequence. Check redirects before later crawl, index and traffic signals.

Use this checklist for each affected page type

Canonical, noindex or redirect decision

I wrote down whether the URL should keep serving visitors. I decided whether this page should appear as its own search result. I compared it with the proposed preferred page rather than assuming they are duplicates. I chose one primary outcome: consolidate, exclude, move or keep indexable. I checked the final status, robots rule and preferred URL in the live response. I confirmed that internal links and the sitemap support the same choice. I tested a representative URL from every affected page template. I recorded the change date and examples for the next crawl review.

The checklist can’t guarantee which preferred page a search engine will select or when a removed page will disappear. It does make the intended outcome explicit and exposes conflicting signals before they spread across a template.

What this evidence can and can’t establish

The live server response can prove which status code, canonical URL and robots rules your website sends now. Google Search Console can show the canonical Google reports and whether the inspected URL is indexed. A crawl checks many URLs and can reveal whether the same setup repeats across a product, service or article template.

Those checks can’t guarantee that Google will select the canonical URL you requested. Google also compares links, sitemaps, redirects and the pages themselves. The checks can’t predict when a noindex rule will take effect either. The search engine must return to the page and process the change first.

Ask a developer or search specialist for help when the settings come from several templates or JavaScript changes the canonical after load. You may also need help when HTTP headers and HTML disagree, or thousands of filtered URLs need one consistent rule. Give the specialist example URLs, the intended page outcome and the evidence you recorded.

Choose the outcome before the tag

Use rel="canonical" for duplicate or very similar pages that must stay live while one preferred URL represents them. Use noindex for a page that must stay accessible but shouldn’t appear in search. Use a permanent redirect when the old page no longer needs a separate visitor journey and a suitable replacement exists.

Starting with the page’s job makes the technical choice easier to explain and much harder to apply by accident.