Noindex vs canonical vs redirect: which one does your page need?

Noindex vs canonical vs redirect: what each one does

Each of these tells Google something different, and each leaves your visitors with a different experience. That second part gets forgotten. A noindex rule hides a page from search but leaves it open to anyone who has the link. A canonical tag keeps every copy reachable and asks Google to show just one. A redirect moves everyone, people and Google's crawler alike, to a new address.

The bigger difference is how firmly Google follows each one. Google's noindex guide calls noindex a rule: once Googlebot reads it, Google drops the page entirely from Search results, whether or not other sites link to it. A canonical is softer. Google's guide to URL canonicalization says that indicating a canonical preference is a hint, not a rule, and its guide to duplicate URLs ranks a permanent redirect and a rel="canonical" tag as strong signals and a sitemap entry as a weak one. Canonical here means the main version Google picks to show from a set of duplicates.

So noindex settles whether a page can appear. A canonical only influences which of several copies appears, and Google can still pick a different one if the evidence points elsewhere. That decides the tool. If a page must never show in Google, a hint isn't enough. If you want copies folded into one main address, noindex is the wrong tool, because it doesn't point anywhere: it just removes the copy.

Here's how the options compare, including the one people forget: letting a page go.

Judge a page by its purpose, then ask six questions

Low impressions tell you how often a page turned up in Google. They don't tell you whether it should. Search Console's help says that, in general, an impression counts whenever a link to your site appears on the current page of results, whether or not the searcher scrolls down to it. So a small number measures exposure, and nothing more.

A page can sit on low impressions for plenty of healthy reasons. Few people search for that exact service in your area. The page is new. The demand is seasonal: Google's guide to debugging traffic drops says demand for some queries changes with trends or seasonality, and suggests looking at 16 months of data to see whether a dip happens every year. Or the page was never meant for search at all, like a booking confirmation or a page for existing customers.

Only that last case is a job for noindex, and you'd know it from the page's purpose without opening a report. Noindexing a page because its numbers look small takes it out of the searches it was getting, however few. If a page covers a real service in an area you actually work, the usual fix for low impressions is a better page. The guide to local SEO seasonality and reporting covers reading the numbers fairly.

Work through these questions in order for each page you're unsure about, and stop at the first yes. They're small technical calls inside local SEO, but they decide which of your pages can be found at all.

1. Is the page gone for good, with nothing on your site that replaces it? Let it return a 404 or 410, and take out your own links to it.
2. Has it moved, merged or been replaced by a page that serves the same need? Use a permanent redirect straight to that page. Google's redirect guide recommends a permanent server-side redirect, wherever possible, when a page's address needs to change in search results. When to merge overlapping SEO pages covers the merge itself.
3. Is it a technical copy of another address on your site, such as the http version, the www version or the same page with tracking tags added? Redirect the copy if nobody needs it to load; use a canonical tag if it must keep working. The duplicates table further down sorts the common cases.
4. Is it a similar but different page competing with another one, like two service pages saying nearly the same thing? A canonical isn't the fix, because it's meant for duplicate or very similar pages and leaves the weaker page live. Merge the two and redirect, or make each one genuinely distinct.
5. Is it useful to visitors but not to searchers? Thank-you pages, customer logins, booking confirmations and staff-only pages fit here. Use noindex, and make sure robots.txt doesn't block the page, or Google never sees the rule.
6. Does it answer a real search that no other page on your site answers? Leave it indexable, whatever its impressions, and improve it if it's thin. The guide on when local landing pages deserve indexing has the tests for suburb pages.

What each instruction looks like, and where your website sets it

You don't need to write code to use these tools, but knowing what each one looks like lets you check your own pages. Open a page in a desktop browser, use the view source option, and search the source for the words robots and canonical. Here is what you're looking for, written out in words so it's easy to match:

• noindex as a meta tag: a line in the page's head reading meta name="robots" content="noindex". This is the form Google's noindex guide gives. Seeing "noindex, nofollow" means a second rule was added that also tells Google not to follow the page's links.
• noindex as a header: X-Robots-Tag: noindex, sent by the server rather than written in the page. Google's robots meta tag specification says the header suits files where a meta tag isn't possible, such as images. It won't appear in the page source, so check it with Search Console's URL Inspection tool instead.
• A canonical tag: a line in the head reading link rel="canonical" followed by href and the full address, such as https://www.example.com.au/hot-water/. Google only accepts it in the head, and asks for the full address rather than a relative path like /hot-water/.
• A canonical for a PDF: Google's duplicate URL guide shows a Link header that names the main address with rel="canonical", for files that have no head section to hold a tag.
• A self-referencing canonical: the page names its own address. Google's duplicate URL guide recommends adding the same self-referential canonical to the main page itself, so this is normal, not a mistake.
• A 301 redirect: nothing to see in the page source, because the server answers with the new address before any page loads. It's set in your hosting, a redirect plugin or your server settings.

Where your CMS handles it, and which duplicates to redirect or tag

Most small business sites set these through page settings, not code. Yoast SEO's help says the plugin adds canonical URLs to WordPress sites, and that you can enter a different one under Advanced in the Yoast SEO sidebar; it also has a setting for whether search engines may show the content in search results. Wix's help says Wix creates a default canonical for every page, a self-referencing one it recommends leaving alone, and warns that changing it may drop the page from your Wix sitemap. On another platform, look in each page's SEO or advanced settings before reaching for code.

Default self-canonicals are fine. The risk is a theme or plugin writing the wrong address: every page canonicalised to the homepage, or still naming http addresses after a move to https. After any theme, plugin or platform change, open the source of one page from each template (home, service, suburb, blog post) and check the canonical names that page's own https address.

Not every duplicate deserves a canonical tag, either. Google's duplicate URL guide describes redirects as the way to get rid of existing duplicate pages, while a canonical keeps the copy reachable. If a duplicate address has no reason to load, redirect it and it's gone for people and Google at once.

Worked example: six quiet pages on one plumber's site

Say a plumbing business in Caloundra reviews its site after a rebuild and finds six pages with low impressions. Same metric on all six. Different answers, because each page has a different job.

The owner starts with the six questions, then opens each page's source to see what is already there. The quote-form thank-you page carries no robots tag at all. The tagged hot water address already names the clean /hot-water/ address in its canonical, because the CMS adds a self-referencing canonical to the clean page and ignores the tracking tags. The past-jobs archive, though, points page 2 and page 3 at page 1, which a theme setting had done without anyone noticing.

Two of the six look alike in a report and need opposite treatment. The thank-you page has no search job, so hiding it costs nothing. The stormwater page has a real search job that happens to be quiet for part of the year, so hiding it would throw away the searches it gets when people need it most.

The redirect row follows Google's site-move guidance, which says to keep redirects for as long as possible, generally at least a year, so Google can pass signals to the new addresses. For the rest of the rebuild checklist, see website migration and SEO handover.

Last, the owner trims the sitemap so it lists only the addresses that should be found: not the thank-you page, the old drains address, the gas page or the tagged hot water link. Google's sitemap guide says to include the URLs you want to see in search results, and its duplicate URL guide treats every sitemap entry as a suggested canonical, so a sitemap that lists the copies argues against the work above.

Mixed signals that undo the work

Most trouble with these tools comes from giving Google two instructions at once, or one it can't read. Check for these before you blame the tool.

• Blocking a page in robots.txt and adding noindex. Google's robots meta tag specification says that if a page is disallowed from crawling, its indexing rules won't be found and are ignored. Its robots.txt guide adds that robots.txt isn't a way to keep a page out of Google, and a blocked address can still show in results without a description.
• Using noindex to choose between duplicates. Google's duplicate URL guide doesn't recommend it within one site, because it blocks the page from Search completely. Use a canonical tag or a redirect instead.
• Pointing a canonical at a page that can't be the main version: one that is noindexed, redirects elsewhere, returns a 404, or names a different canonical of its own. Each of these asks Google to prefer an address you've told it not to use. Point the canonical at the final, indexable address.
• Pointing different signals at different pages. Google asks you not to name different canonicals for the same page through different methods. A common slip: the canonical tag names one address while the sitemap lists the copy.
• Leaving noindexed, redirected or removed addresses in the sitemap. A sitemap should list the pages you want found, so take these out when you change them.
• Redirecting everything to the homepage. Google's site-move guidance warns this can confuse users and might be treated as a soft 404. Send each old page to its closest match, or let it return a 404.
• Chaining redirects. Googlebot can follow up to 10 hops, but Google advises redirecting to the final address directly and keeping any chain ideally to no more than three.
• Treating the Removals tool as permanent. Search Console's help says a temporary removal lasts about six months, and Google's duplicate URL guide says not to use the tool for canonicalisation because it hides every version of the address.
• Linking internally to the copy. Google's duplicate URL guide asks you to link to the canonical address rather than a duplicate, so menus, buttons and in-text links should all use the main version.

How to check what Google did

Google only acts on these changes after it recrawls the page, and it can disagree with your canonical. So check, using two parts of Search Console, and give it time.

Start with the URL Inspection tool. Compare the user-declared canonical with the Google-selected canonical. If the page isn't a copy of anything, Search Console's help says a user-declared value of None is fine. The Indexing allowed? line shows whether the page carries a noindex rule, and Crawl allowed? shows whether robots.txt blocks it. Use Test live URL to check the current version of the page rather than the last one Google stored, which is how you confirm a new noindex tag is really there.

Then read the Page indexing report. Several of its reasons look like errors but are exactly what you asked for. The table shows which to leave alone and which to act on, using the report's own descriptions.

Once you've corrected an issue, validate the fix in the report. Search Console's help says validation typically takes up to about two weeks, and in some cases much longer. For more on reading audit output, see what an SEO audit should deliver.