A 301 URL redirect tells browsers and search engines that a page has moved permanently. The server returns a 301 response with a Location header pointing to the new address. For an online store, use it when a product, collection, or information page moves for good. Map the old address to the closest relevant replacement, then check both the response and the page shoppers actually reach.
A redirect that ends on the homepage may look successful in a status checker while failing the shopper who followed a link to a specific product. The destination matters as much as the code.
Runner AI publishes this guide. HTTP and search guidance comes from MDN and Google. The Runner example describes inspected source and regression tests, not a live store migration or a promise that every store has the feature enabled.
What a 301 changes, and what it does not
MDN’s 301 reference describes a permanent move to the address in the response’s Location header. The browser then requests that address. A redirect does not copy the old page’s products, images, stock, or checkout settings to the new store.
Google recommends permanent server-side redirects when a page’s search-result URL should change. Google treats the redirect as a signal that the destination should be canonical. That is not a guarantee of unchanged rankings or an immediate update in search results.
Keep these choices separate:
| Situation | Appropriate decision |
|---|---|
| The same product moves to a new permanent address | Redirect the old URL to the new product page |
| Two overlapping guides become one guide | Redirect to the combined page if it answers the old page’s purpose |
| A page moves only temporarily | Consider a temporary redirect rather than declaring a permanent move |
| A product is briefly out of stock | Do not change its URL solely because stock is unavailable |
| A removed product has no useful replacement | Review removal handling instead of sending every visitor to an unrelated page |
For the stock decision, see our out-of-stock product guide. For a broader platform move, use the store migration planning guide alongside a redirect map.
Build the map before changing the URLs
Start with a table of old URLs and intended destinations. Collect addresses from your existing sitemap, internal links, search reports, and important past campaigns. Prioritize links that still bring visitors or appear in customer emails.
Here is an illustrative map for a store moving from WordPress-style paths to a new storefront. These are example paths, not a required Runner URL structure.
- Same product. Send
/product/blue-cap/to/us/products/blue-capwith a permanent redirect. - Equivalent collection. Send
/product-category/hats/to/us/collections/hatswith a permanent redirect. - Same delivery information. Send
/shipping-information/to/us/shippingwith a permanent redirect. - Unresolved removal. Leave
/product/retired-cap/out of the import until the merchant identifies a relevant replacement or removal response.
Do not fill the unresolved destination with / just to make the spreadsheet complete. Open the proposed replacement and ask whether someone arriving from the old page would recognize what they came for.
Record the intended status alongside each mapping. Keep the original export as a backup and keep unresolved rows separate from the import file. A list with fewer reviewed rules is more useful than a larger list of guesses.
If the domain changes too, the old domain must still be able to receive requests and return the redirects. Changing DNS alone does not define an old-product-to-new-product mapping.
Importing an existing redirect list needs a second review
A redirect export can contain more than simple old-address-to-new-address rules. It may include patterns, conditions, disabled entries, or removal responses. A destination platform that accepts whole paths cannot necessarily reproduce those behaviors.
Runner’s checked-in redirect implementation illustrates this boundary. Its import reader recognizes exports from Rank Math, Yoast SEO, and Redirection, but it imports only supported whole-address redirects. It reports skipped entries such as pattern rules, conditional rules, disabled rules, unsupported statuses, and later duplicates within the file.
That means an accepted file is not proof that every source rule transferred. Compare the import summary with the original list. Review skipped rows individually rather than changing their meaning until the importer accepts them. A rule from the file can also replace an existing store rule for the same old address, so inspect collisions before saving.
The Runner controls require both feature access and compatible storefront code. Older storefronts may not have the redirect lookup. Product and category migration does not itself create the full redirect map in the inspected implementation. Confirm support for your store before planning a cutover around it.
For product evaluation, see Runner’s ecommerce redesign capability. For the separate domain-connection task, use the custom domain guide. Neither replaces checking the individual redirects.
Verify the destination, not just the 301
Test the original public URL, not only the new address. A new page can work perfectly while its old link still returns an error.
- Open the old URL in a fresh browser session.
- Check the redirect response and its
Locationin the browser’s Network panel. - Follow the chain to its final address and confirm that the intended product or information is present.
- Check a mobile viewport and the next useful action, such as choosing a variant or opening the relevant collection.
- Repeat important links with harmless campaign parameters and compare what survives.
Use a record like this for each priority URL:
| Check | Passing evidence |
|---|---|
| Redirect response | The old URL returns the intended permanent status and destination |
| Final response | The destination returns the intended page, not an error or login screen |
| Product identity | The title, image, and product details match the mapped item |
| Query handling | Harmless campaign parameters behave as intended |
| Chain | No repeated address or avoidable intermediate destination |
| Updated links | Navigation and newly sent campaigns use the final URL directly |
Runner’s storefront regression tests include an old product URL carrying utm_source=mail to a new product path. They also cover a target with its own query string and a chain of same-store redirects resolved to its end. Those are useful test cases for a migration checklist, not evidence that your particular store passed them.
Do not send private checkout links, password-reset URLs, signed download links, or customer details to public redirect tools. A public checker may also see different behavior from a logged-in browser.
If addresses repeat or navigation never finishes, switch to diagnosing too many redirects. That is a routing failure, not a reason to keep adding more rules.
Related questions
Is a 301 or 302 redirect permanent?
A 301 declares a permanent move. A 302 is temporary. Choose based on whether the page is moving for good, not whether one code appears to fix a browser symptom. Google’s redirect documentation explains how permanent and temporary redirects send different canonicalization signals.
What is the difference between 301 and 308?
Both indicate permanent moves. A 308 preserves the request method, while a 301 can result in a POST becoming a GET, as MDN explains. Do not apply product-page redirect rules to payment callbacks, order submissions, or API traffic without reviewing those contracts separately.
Can a redirect preserve every search ranking?
No. A permanent redirect is a signal about the page’s new location, not a ranking guarantee. The replacement content, internal links, crawlability, and the rest of the site move still need review. Monitor the actual search results after the change rather than promising zero traffic loss.
Does a redirect replace updating internal links?
No. Use the final address in navigation, product references, and new campaigns. Keep the redirect for people and systems that still use the old address. The useful outcome is a shopper reaching the right page, not merely a spreadsheet full of 301s.