Changing a page's address can seem like a small adjustment: update the link and carry on working. But the old URL may still appear in search results, bookmarks, a newsletter or an external website. Without a proper route, anyone opening it risks encountering an error or a destination that does not meet their needs.
301 and 302 redirects take visitors to another address, but communicate different intentions. A 301 indicates a permanent move; a 302 indicates a temporary one. Choosing the right code matters, but is not enough: you must identify a relevant destination, check the rules and update the site's links. This guide explains how to approach the change in a way that is understandable even for someone coordinating the project without personally configuring the server.
What a redirect is
A redirect is a response inviting the client, such as a browser, to request a resource at another address. With HTTP redirects, the server returns a status code and normally indicates the destination in the Location header. The visitor can then reach the new page without having to search manually for the content.
For example, the path /old-service can lead to /new-service. This example describes only a relationship between addresses: it is not a ready-to-copy rule. The MDN documentation on 301 illustrates the response and destination. For the person managing the website, the operational point is knowing which request triggers the move and where navigation actually ends.
When to use a 301
The 301 code communicates that the resource has a new permanent address. It is appropriate when a page is being moved permanently and the old URL must continue to guide people arriving through earlier links. A definitive slug change or an established reorganization of content are situations to consider in this way.
The decision must reflect the actual project. Before setting it up, ask whether the new destination will represent that content in the future and whether the old address will need to become operational again. Do not choose a 301 just because it is often associated with SEO: if the move is provisional, it would communicate a different intention. Documenting the reason for the change helps whoever maintains it later.
When to use a 302
The 302 code indicates that the resource is temporarily at another address. It can be appropriate when the old URL remains the reference to retain and the move to an alternative destination is intended for a limited period. A recent change is not enough: there must be a concrete reason to consider it reversible.
One documented case is an experiment sending some visitors to a page variation. In its guidance on website testing, Google recommends a 302 for this kind of temporary redirect. Even a test needs an owner, a planned conclusion and a final behavior: a forgotten rule can remain active long beyond the experiment.
The question to ask before choosing
The main question is whether the content has moved home or is using a provisional destination. In the first case, consider a permanent redirect; in the second, a temporary one. The calendar alone does not resolve the issue: a change intended to last can be permanent from day one, while a long detour may still have a temporary purpose.
Write down in one sentence why the old address is changing, which page replaces it and who decides when any detour ends. If those details are unclear, define the project before adding rules. The HTTP code should express a decision about content and user journeys, rather than make that decision for you.
What it communicates to search engines
Google also distinguishes permanent from temporary redirects when choosing the representative URL for content. Its official redirect guide describes a permanent redirect as a signal favoring the destination as the canonical URL; a temporary redirect communicates a different intention. This is not a promise of rankings or traffic.
It is therefore incorrect to describe a 302 as an automatic penalty, or a 301 as a guarantee of retaining every previous result. The response should match the move. When assessing the effect, also consider the quality and relevance of the new page, links, website availability and signals that might point to conflicting destinations.
Prepare a map of old and new addresses
Before making changes, list the affected pages. For each old URL, indicate the intended destination, type of move, reason and person who must approve it. A shared spreadsheet may suffice for a small project; what matters is that the relationship is verifiable and does not depend on the implementer's memory.
Collect addresses from the site, its most-used pages and materials published by the company. Where relevant, include downloadable documents and links used in campaigns. Flag uncertain cases instead of assigning a generic destination. This map becomes the basis for implementation and the reference for testing, avoiding improvised decisions at release time.
Choose a genuinely relevant destination
Someone opening an old link expects a specific answer. If they were seeking a service page, arriving at the homepage may force them to start searching again. The destination should therefore preserve the meaning of the previous page where possible and allow the visitor to continue their journey.
Before approving a match, compare the content, purpose and requested action. An updated page about the same service may be a good replacement; a loosely related section may not be. Do not use a redirect to conceal an unclear structure. If several pieces of content have been merged, check that the resulting page genuinely addresses the main needs covered by those removed.
When a 404 or 410 is appropriate
Not every deleted page requires a redirect. If the content no longer exists and has no relevant replacement, a 404 or 410 response can accurately describe the situation. The Google documentation on crawling errors distinguishes moved content from content removed without an equivalent replacement.
An error page can still help visitors with navigation and useful guidance while retaining the appropriate HTTP status. Redirecting everything to a generic page simply to remove errors from a report does not necessarily solve the user experience. The choice depends on whether a genuine replacement exists, not on a desire to eliminate every unavailable URL.
Consider URL parameters and variations
An address can appear with parameters, capitalization differences, different paths or a trailing slash. Before applying a broad rule, understand which variations are valid and which information must be retained. A parameter may support tracking, but it can also determine content or functionality: removing it without checking can alter the result.
Prepare representative examples and test them individually. Document whether the destination should retain or remove parameters, without assuming the chosen system automatically does what you intend. For catalogs, filters and application-generated pages, involve someone who understands the website's behavior. An apparent cleanup of addresses must not make necessary information or operations unreachable.
Avoid redirect chains
A chain occurs when an old address leads to a page that redirects again before reaching the final page. It can arise through successive changes: first the path changes, then the domain, then the preferred address version. Each rule may look correct in isolation while the overall route becomes hard to follow.
When updating a map, assess whether the old URL can point directly to the current destination. Check the actual steps, not just the page that eventually opens. Keeping the route simple makes behavior easier to verify and problems easier to identify. There is no need to wait for a chain to cause an obvious error before revisiting rules that have become unnecessarily complicated.
Recognize and eliminate loops
A loop occurs when rules return visitors to an address already visited, without reaching a stable destination. For example, one rule may enforce a trailing slash while another removes it. The same kind of conflict can arise when different layers manage the domain, protocol or paths with incompatible settings.
Before adding a rule, check existing ones in the CMS, server and any intermediary services. If the browser reports too many redirects, reconstruct the entire sequence and identify where it turns back. Correcting the conflict at its source is more reliable than adding exceptions without understanding which component produces each response.
Update internal links too
A redirect preserves a route for people using old references, but company-managed links should be updated when a move is permanent. Menus, buttons, related articles and links within text may continue pointing to the previous address if the only change is configuring the redirect rule.
Use the map to review affected content and check templates that generate links automatically. Also examine email signatures, campaign pages and materials that can be changed. The redirect then provides continuity for external or historical references, while ordinary navigation uses the current route and becomes easier to maintain.
Coordinate sitemaps and canonical signals
The sitemap and canonical annotations should be considered alongside the new structure. The Google guide to canonicalization describes several signals for indicating a preferred URL. A canonical annotation does not move a visitor as a redirect does: it communicates a preference to search engines.
When a page moves permanently, check that the destination does not still identify an old or unrelated address as preferred. Also review what the CMS generates automatically. Inconsistent signals make the site's intention harder to understand. For the project coordinator, asking for a combined review is more useful than treating these as three separate boxes to tick.
Prefer a server response when available
A redirect can be implemented at different layers. An HTTP response communicates the move before loading a page that executes other code. Script-based solutions or page refreshes require different considerations and should not be treated as identical simply because the browser reaches the same destination.
Before choosing, establish which tools the hosting provides and what constraints the application imposes. The technical owner should verify that the intended status code is returned, not merely that the address bar changes. If a concrete limitation requires an alternative solution, document it and plan to check its behavior using browsers and analysis tools.
Configure the rule at the right layer
A CMS panel, web server or intermediary service can manage a redirect. Choose the layer with an understanding of the existing configuration and who maintains it. Duplicating the same responsibility across several tools makes it harder to know which setting takes effect and where to fix a problem.
For Apache, for example, the documentation distinguishes permanent redirect directives and rules with an explicit response code. However, there is no universal line to paste into every site: paths, existing rules and context matter. Before changing production, preserve the configuration and test behavior in a suitable environment.
Account for caching
A browser or intermediary may retain responses under the applicable caching rules. A 301 is defined as heuristically cacheable by the HTTP specification. It is therefore important not to use it as an experiment before deciding the destination: correcting the server does not necessarily mean that every client immediately forgets a previous response.
During testing, compare network requests with what appears in a session already used. Check any site or intermediary-service caches and follow the relevant update procedure. Conversely, do not assume that a 302 can never be cached: behavior must be assessed alongside the actual headers and settings.
Take care with forms, POST and APIs
A normal page visit commonly uses a GET request, but a website also contains form submissions and application operations. In these flows, distinguishing permanent from temporary is not enough: you must know whether the request method and data need to be preserved and where they may be sent.
For historical reasons, RFC 9110 allows POST to change to GET with 301 and 302. Codes 307 and 308 express method-preserving redirects, respectively temporary and permanent. For forms, payments and APIs, have the technician assess application behavior and security before reusing a rule intended for informational pages.
Manage domain changes and moves to HTTPS
A domain move requires considering both the old and new environments. Visitors may continue opening historical addresses: the old domain must be able to receive the request and respond as intended. Alternative names and protocol versions should also be included in testing, according to what was actually available.
For HTTPS requests, check certificates and the connection before the redirect: an error at that stage may prevent the new page from being reached. Do not test only the new domain. Prepare representative addresses and clarify who maintains DNS, hosting and certificates during the transition. Content migration and continuity for old references must be planned together.
Preserve the language context
On a multilingual website, an Italian page should lead to a destination consistent with the expected language and content where available. Redirecting every version to one page can lose the context for someone arriving through a specific link. The map should therefore include the language versions that actually exist.
Involve the people responsible for content to establish the matches. Do not assume similar-looking paths are equivalent translations or that changing one part of the URL is enough. Also test the language selector and links between versions after the move. The goal is to preserve an understandable route for the reader, not merely produce a technically valid response.
Test the old address and the destination
Testing should start at the URL a user might open, not just at the new page. Check the returned code, indicated destination and any intermediate steps. At the end, confirm that the expected page is available, contains the right content and allows the intended action to be completed.
Test links with and without relevant parameters, and check from a context that does not depend on an administrator session. For more complex flows, repeat actual operations using test data. Record the outcome, date and issues in the map. A simple “it opens” is too limited a check when it can conceal an unintended code or the wrong destination.
Monitor after publication
Release does not finish the work. Checking errors, frequently visited routes and requests still reaching previous addresses helps identify missing matches. Compare the site's behavior with the approved map and collect reports from users or departments using historical links.
Search Console can help review crawling and the page Google selects as canonical. The canonicalization troubleshooting guide describes using URL Inspection. Read this information alongside direct website tests. A change in reports requires interpretation: it should not automatically be attributed solely to the 301 or 302 code.
Decide how long to retain redirects
An old link may remain in use long after a move. In its site migration guidance, Google recommends retaining redirects for as long as possible, generally at least one year. This is not a deadline after which every historical link ceases to have value.
Assess incoming requests, known external links and business needs before removing permanent rules. For temporary rules, schedule a review linked to the reason for the detour. In both cases, retain an owner for the decision: unexplained rules become difficult to remove and can survive several website redesigns without anyone knowing why they exist.
A checklist before confirming
Before considering the change complete, verify that:
- Every old URL has a decision and a relevant destination where one is intended.
- The code correctly expresses a permanent or temporary move.
- There are no loops or avoidable intermediate steps.
- Internal links, the sitemap and canonical signals are consistent.
- Forms, parameters, languages and HTTPS versions have been tested where relevant.
- There is an owner and a date for the next review.
The checklist does not replace knowledge of the site, but makes discussion between content managers and system administrators more concrete. For cases excluded from the move, also document the decision to remove a page without replacing it.
Frequently asked questions
If I change only the final part of a page's address, do I need a redirect?
If the old address must continue leading to the content, provide a route to the new one. Before doing so, check whether the CMS has already created an automatic rule. Testing must start at the old URL and check the actual response and destination.
Does a 302 automatically harm SEO?
No. It is a suitable code for communicating a temporary move. Problems arise when behavior does not match the project's intention or other signals are inconsistent. The choice should follow the actual move, without automatic promises about search results.
Can I send all deleted pages to the homepage?
It is not a good general solution. Someone opening a specific page may not find what they sought. Identify a relevant replacement; if none exists, consider a correct resource-unavailable response with useful guidance for continuing navigation.
Can I change a 302 to a 301 when the move becomes permanent?
Yes, after confirming the decision. Update the rule, check relevant caches and repeat tests on old addresses. Also verify links and site signals so the change is not limited to the code returned by the server.
Conclusion: communicate the change consistently
A 301 suits a permanent move, while a 302 suits a temporary detour. Quality also depends on relevant destinations, understandable rules and complete checks. A correct redirect guides someone arriving through an old link toward the content they expect.
Preparing a map, involving content and infrastructure owners, checking the actual route and maintaining it over time helps prevent avoidable errors. Aim for a clear transition for users and systems, with decisions documented and verifiable even when the website changes again.
Would you like to explore this topic for your business? Azienda Digitale can help you assess the right solutions and put them into practice. Azienda Digitale