Canonical vs 301 redirect vs 302: which to use and when

The canonical vs 301 redirect choice comes down to one question: should people still be able to open the duplicate URL? If the old URL has no reason to exist any more, use a 301 redirect, which sends both visitors and Google to the new address. If the duplicate has to stay reachable, as a filtered product list or a tracking-parameter URL does, leave it live and add a canonical tag pointing to the main version. A 302 is for moves you plan to reverse.

The three tools overlap enough that they get swapped for each other, and the wrong one causes problems that only show up later in the index. This guide covers how Google documents each one, which to pick in the situations that come up most, and what to do when they conflict.

What each one tells Google

A 301 redirect is a server response that says the page has moved permanently. The browser never shows the old page. Google follows the redirect and treats it as a signal that the destination should be the canonical URL, the one it indexes and shows in results. A 308 does the same job.

A 302 redirect says the page has moved for now. Visitors are forwarded in exactly the same way, but Google's documentation describes the indexing side differently: Google follows the redirect without being influenced by it in the way it is by a permanent one, which may help keep the old URL in search results. A 307 is the same kind of temporary redirect.

A canonical tag (rel="canonical") redirects nobody. Both URLs keep loading. The tag is a note in the page's head that names the URL you would prefer Google to index. Google describes the link element as a strong signal, but still a signal: indicating a canonical preference is a hint, not a rule, and Google can choose a different URL if other evidence points elsewhere.

When to use a 301, a 302 or a canonical tag

The table sets the three side by side.

These questions settle the usual cases:

1. Does anyone still need to open the duplicate URL? If not, redirect it. Google's guidance is to use a redirect only when deprecating a duplicate page, and a canonical tag when the duplicates stay.
2. Is the change permanent? Google's wording is to use permanent redirects when you are sure the redirect will not be reverted. If you expect to undo it, use a 302.
3. Can you change the server response at all? On some hosted platforms you cannot add redirects for certain URL patterns. A canonical tag is then the available tool, with the understanding that it is weaker than removing the duplicate.

One limit on the canonical tag: the link element works for HTML pages only. For a PDF or another non-HTML file, the canonical has to be sent as an HTTP header, which Google supports for web search results.

Does a canonical pass link equity like a 301?

When Google accepts the canonical, yes: links pointing at the duplicates are counted for the canonical URL. Google lists consolidating signals for similar or duplicate pages as one of the reasons to specify a canonical in the first place, and links are among those signals. On redirects, Google states that 301 and other permanent redirects do not cause a loss in PageRank.

The difference is certainty. A 301 leaves Google with one URL to choose from, because the other one no longer returns a page. A canonical tag leaves two working URLs and asks Google to agree with your choice. If the two pages differ in their main content, or if internal links, the sitemap and the tag point in different directions, Google may keep the URL you did not want. Consolidation then does not happen the way you planned.

So a canonical tag is not a soft 301 for pages that are merely similar. Pointing a canonical from one article to a different article on a related topic is asking Google to treat two different pages as one, and it is free to decline. If you want the value of an old page to move to a different page, redirect it.

302 vs 301 for SEO, and when Google treats a 302 as permanent

For visitors there is no difference between a 302 and a 301. For indexing, a 301 tells Google to swap the old URL for the new one, and a 302 tells it to keep the old one. Using a 302 for a permanent move therefore sends the wrong instruction: the old URL can stay in the index while the new one waits.

Whether Google eventually treats a long-running 302 as permanent is a fair question with no documented number behind it. Google's redirect documentation does not publish a time after which a temporary redirect is reclassified. What it does document is that canonical selection weighs several signals together, including redirects, HTTPS, sitemap inclusion and rel="canonical", and that Google makes the final choice. A 302 that stays in place while your internal links, sitemap and canonical tags all name the destination gives Google plenty of reasons to pick the destination anyway. That outcome is Google's call, and a migration plan should not depend on it.

The practical rule: if a move is permanent, return a 301 or 308 and remove the doubt. 302s often exist by accident, because some frameworks and plugins issue a temporary redirect by default. A redirect check during a technical review should list every 302 and ask of each one whether the original URL is really coming back.

Google also classifies some non-server redirects. An instant meta refresh (0 seconds) is interpreted as permanent and a delayed one as temporary. JavaScript redirects are followed only if rendering succeeds, and Google advises using them only when server-side or meta refresh redirects are not possible.

What happens when a canonical points to a redirected URL

The page says "index that URL", and that URL answers "I have moved". Google has to resolve two instructions that do not match, and you have left the result to its judgment. This pattern usually appears after a migration. The redirects go in, but the canonical tags in the templates still carry the old address, or the HTTP version, or the version without a trailing slash.

The fix is mechanical. A canonical should name the final URL: one that returns a 200 status, is not redirected, and is not blocked or set to noindex. The same applies to the reverse conflict, a page that redirects to B while B's canonical points back to A. That loop gives Google nothing consistent to follow.

Google's guidance covers the wider version of this problem too: do not specify different URLs as canonical for the same page through different techniques. If the sitemap lists one URL, the canonical tag names another and internal links use a third, each signal weakens the others. Pick one URL per page and make the redirect targets, canonical tags, sitemap entries, hreflang annotations and internal links all agree on it.

Handling duplicate product and filter URLs

Online shops produce duplicates by design. One product is reachable through several category paths. Colour and size variants get their own parameters. Sorting and filtering create a new URL for every combination. None of these can be redirected, because shoppers are using them.

This is canonical tag territory, with choices to make:

• Same product under several paths: pick one URL as the product's home, set the canonical on every path to it, and link to it internally.
• Sort order and view parameters: these change the order of the same content. Canonicalise them to the unsorted category URL.
• Tracking parameters such as campaign tags: canonicalise to the clean URL. A self-referencing canonical on every page handles this without extra rules, because the tag carries the clean address whatever parameters were added.
• Filter combinations: decide whether a filtered page deserves to be found in search. A filter that matches how people search can be its own indexable page with its own canonical. The rest can point to the unfiltered category.

A canonical tag does not stop crawling. Google has to fetch a filtered URL to see the tag on it, and its faceted navigation guidance says rel="canonical" may reduce crawl volume of those URLs over time but is generally less effective in the long term than blocking them. Where filter URLs do not need to be indexed at all, Google's suggested route is to disallow them in robots.txt. For filter URLs you keep crawlable, the same guidance recommends a consistent parameter order and a 404 response for combinations that return no results.

Do not combine the two on the same URL. If a filtered URL is blocked in robots.txt, Google cannot read its canonical tag, so the tag does nothing. Google also advises against using robots.txt or noindex as a way to pick a canonical within a site. Choose one approach per URL pattern. For larger catalogues this mapping is the core of ecommerce SEO work.

Site migration: redirect map vs canonicals

In a migration the two tools have separate jobs and neither replaces the other. The redirect map moves the old URLs. The canonicals confirm the new ones.

Google's site move guidance sets out the sequence:

1. Build a URL map that pairs every old URL with its new equivalent.
2. Implement server-side permanent redirects (301 or 308) from each old URL to its match.
3. Give each new URL a self-referencing canonical tag, and update hreflang annotations if the site uses them.
4. Change internal links to the new URLs so the site does not rely on its own redirects.
5. Submit a sitemap containing the new URLs.
6. Keep the redirects in place for as long as possible, generally at least one year.

Two details in that guidance deserve extra care. First, redirect each old URL straight to its final destination. Googlebot can follow up to 10 hops, but Google recommends keeping chains short, ideally no more than 3 and fewer than 5. Second, do not redirect many old URLs to one irrelevant destination such as the home page. Google can treat that as a soft 404. Merging several old pages into one new page that covers the same content is fine.

Trying to migrate with canonical tags alone, leaving the old site live and pointing its canonicals at the new domain, keeps two copies available to visitors and leaves the outcome to Google's choice. A domain move is a permanent change, and the permanent redirect is the tool built for it. A redesign is the moment these mistakes get made, so the URL map belongs in the web design project plan from the start.

What this means for websites in the Thai market

Bilingual Thai and English sites raise a question the single-language guides skip: should the English page be canonical for the Thai one? No. Google treats language versions as duplicates only when the main content is in the same language. A Thai page and its English translation are separate pages that should each carry a self-referencing canonical and be connected with hreflang. Pointing the canonical of /th/ pages at the English version asks Google to drop the Thai pages from the index.

Thai-script URLs add a mechanical trap. A slug written in Thai can appear in two forms, as readable Thai characters and as a percent-encoded string. Redirect rules, canonical tags and sitemap entries should all resolve to the same final URL in one consistent form. When a redirect rule is written against one form and the request arrives in the other, the rule can fail to match and the old URL returns a 404 with no redirect. Test migration rules with real Thai URLs as well as ASCII ones.

Shops that run seasonal campaigns for dates such as 11.11 or Songkran face the 301 or 302 decision every few months. If the campaign URL will be reused next year, keep it live or redirect it temporarily with a 302 during the off-season. If it is gone for good, use a 301 to the closest matching category.

Frequently asked questions

Is a canonical tag the same as a 301 redirect?

No. A 301 redirect moves visitors and search engines to a new URL and the old one stops being served, while a canonical tag leaves both URLs working and only states which one you prefer Google to index. Google treats a permanent redirect as a signal that the target is canonical and treats the canonical tag as a hint it can overrule.

Can I use a canonical tag and a 301 redirect together?

Yes, as long as they agree. The usual setup is a 301 from the old URL to the new one, plus a self-referencing canonical on the new URL. A redirected URL never shows its own HTML, so a canonical tag placed on it is not seen. The one that counts is the tag on the destination.

Does a 302 redirect hurt SEO?

A 302 does not hurt when the move is temporary, because keeping the original URL indexed is the intended result. It causes trouble when used for a permanent move, since Google is told to keep a URL you have abandoned. Change those to 301 or 308.

How long should 301 redirects stay in place?

Google's guidance is to keep them for as long as possible and generally for at least one year. Other sites and old bookmarks keep sending visitors to the old URLs long after that, so there is rarely a reason to remove a redirect that still receives requests.

Should paginated or filtered pages canonicalise to the first page?

Filtered and sorted pages can canonicalise to the unfiltered category when they show the same items in a different order or subset. Page 2 of a list is a different case, because it shows different items from page 1 and is not a duplicate of it. A canonical is for duplicates, so paginated pages normally keep their own.

Redirect and canonical errors rarely show on the page itself. They show up later as the wrong URL in search results or a migration that loses traffic. Checking redirect types, chains and canonical targets across a whole site is part of a technical SEO audit, and the rest of the work is outlined on the Relevant Audience SEO services page.