Direct answer: Use a permanent server-side redirect—normally 301 or 308—when a URL has permanently moved and users should land on a relevant replacement. Use rel=canonical when duplicate or very similar URLs must remain accessible but one URL is preferred. Use noindex on a publicly accessible page that may stay live but should not appear in Google Search; Google must be allowed to crawl the directive. Return 404 or 410 when content has no relevant replacement. Protect private content with authentication, not robots directives.
Begin with the intended experience—move, consolidate, exclude, remove or protect—then implement one clear outcome. Compatible canonical signals can reinforce each other; contradictory instructions create uncertainty.
Quick URL decision table
| Situation | Primary action | What it means |
|---|---|---|
| Page permanently moved | 301 or 308 redirect | Send people and crawlers to the closest relevant replacement |
| Move is temporary | 302, 303 or 307 redirect | Use when you expect the source URL to remain preferred |
| Duplicates must remain available | rel=canonical |
Declare the preferred representative without forwarding users |
| Public utility page should not rank | noindex |
Keep it crawlable so the directive can be read |
| Content is gone with no replacement | 404 or 410 | Report the removal honestly and fix links and sitemaps |
| Content is confidential | Authentication | Restrict access; search directives are not security controls |
Use a permanent redirect for a permanent move
A redirect changes the destination for users and crawlers. Use a permanent server-side redirect when a URL moves or a removed page has a genuinely equivalent successor. Google treats permanent redirects as a strong signal that the target should become canonical.
Use a temporary redirect only when the change will be reversed. Google follows temporary redirects but does not use that redirect itself as a signal that the target should become canonical; other signals can still make the target indexable. Choose the status that accurately describes the change for browsers and other clients too.
Point each source directly to the final destination, update internal links, and list the destination—not the redirecting URL—in the sitemap. Avoid long chains. Do not send unrelated old URLs to the homepage: an irrelevant destination can confuse users and may be treated as a soft 404. For broader launch sequencing, use the website redesign SEO checklist.
Use canonical when duplicates must remain accessible
A rel=canonical annotation is a strong canonicalization signal, not a command; Google may still select another URL. It suits duplicate or very similar pages that must remain accessible. Users can still visit the duplicate because a canonical does not redirect or block access.
Implement it consistently:
- use an absolute URL and point directly to the final preferred page;
- place an HTML canonical only inside a valid
<head>; - use a
LinkHTTP header when a non-HTML file needs a canonical; - make the target crawlable, indexable and representative of the duplicate;
- add a self-referencing canonical on the preferred page;
- use the preferred URL in internal links and the XML sitemap.
Google recommends choosing one canonical delivery method because simultaneous HTML and HTTP declarations are easier to misconfigure. Redirect, canonical and sitemap signals can align around the same preferred URL, but they should not point to different destinations. A canonical is not a way to hide weak content, secure data or prevent crawling.
Use noindex for public pages that should not appear in Search
A noindex robots meta tag or HTTP header tells supporting search engines to remove a page after they crawl and process the directive. It can suit publicly accessible site-search results, post-action confirmation pages or other public utility pages that should not be search destinations.
Use a robots meta tag for HTML or an X-Robots-Tag response header for resources such as PDFs. Remove the URL from the canonical XML sitemap, but do not block it in robots.txt: a crawler that cannot access the page cannot read its noindex. Removal can take time until the URL is recrawled.
Do not use noindex to choose a canonical within one site. If the page is a duplicate, use rel=canonical; if it must be excluded, use noindex. These are different intents.
Use 404 or 410 when no relevant replacement exists
Return a genuine 404 (Not Found) or 410 (Gone) when content has been removed and no useful equivalent exists. Google currently treats 404 and 410 the same for Search, so choose the status that accurately describes your application. Neither needs an unrelated redirect.
A helpful error template can offer navigation and search, but the HTTP response must remain 404 or 410. Remove the URL from sitemaps and update internal links. Intentional not-found responses do not harm the indexing or ranking of the rest of a healthy site.
If a sensitive or urgent URL must disappear from Google quickly, the Search Console Removals tool can temporarily hide it. That request lasts about six months; make the removal permanent at the source with content removal, password protection or noindex, as appropriate.
Protect private content with access control
Require login or password protection for confidential documents, customer records, internal dashboards and other restricted material. A noindex page remains accessible to anyone who has its URL, while robots.txt only controls cooperative crawling. Neither is a privacy or authorization system.
Avoid contradictory combinations
noindexas canonicalization: use canonical for duplicates and noindex for exclusion.- Robots block plus
noindex: the block can prevent the directive from being read. - Redirecting URL in a sitemap: list the final canonical URL instead.
- Canonical to a redirect or error: point directly to the intended final page.
- Different canonical targets: align HTML or HTTP canonical, redirects, links and sitemap signals.
- Every removed URL redirected home: use a relevant replacement or a truthful 404/410.
Build a per-URL disposition sheet
- Export affected URLs from crawls, sitemaps, analytics, Search Console and known backlinks.
- Record the user purpose, current status, indexability and closest equivalent for each URL.
- Assign one action: keep, temporary redirect, permanent redirect, canonical, noindex, remove or protect.
- Generate redirects, canonicals, internal links and sitemaps from the approved decisions.
- Test response codes, redirect hops, robots directives and rendered canonicals before release.
- Crawl production after deployment and monitor unexpected index changes.
Verify the outcome after release
Check the final HTTP response, redirect target, canonical, robots meta and X-Robots-Tag. Confirm that internal links and the sitemap agree. In URL Inspection, compare the user-declared canonical with Google’s selected canonical and review the rendered HTML. Re-evaluation can take time; investigate page similarity and technical signals before repeatedly requesting indexing.
For broad site diagnosis, use the technical SEO audit checklist; for report-level diagnosis, follow the Search Console Page Indexing workflow. PAKWM’s SEO service can help define a URL policy and validate implementation.
Primary sources
- Google: canonical URLs and consolidation signals
- Google: redirects and Search
- Google: block indexing with noindex
- Google: build and submit a sitemap
- Google: HTTP status codes and crawlers
- Google: troubleshoot crawling errors
- Google: site moves with URL changes
- Google: remove a page from Search
- Google: canonicalization troubleshooting
Need a URL disposition map before changing production? Request a quote from PAKWM and share the current URL export plus examples of duplicates, moves and removals.