Our review of StoreBuilt’s URL-change guidance highlights a recurring diagnostic trap: a saved mapping is configuration, while a working redirect is an observed HTTP response. The admin can show the rule you intended without proving that the source URL is eligible for that rule. Adding more entries before checking the response usually makes the investigation harder.
This guide is for UK ecommerce teams with a specific Shopify redirect that is not working. It starts with the source URL, separates platform limitations from browser behaviour, and builds a concise evidence trail. It is different from planning a migration or deciding whether a product handle should change in the first place.
In this guide
- Record the exact failing journey
- Check whether the source is still live
- Classify the response before choosing a fix
- Recognise paths the native tool cannot handle
- Make market paths explicit
- Distinguish caching from an unchanged rule
- Choose a destination that fulfils the original intent
- Remove chains and update owned links
- Verify search signals after the repair
- StoreBuilt point of view
Record the exact failing journey
Copy the full address from the customer-facing link. Include the domain, locale subfolder, path and query string. A redirect tested on the main UK domain does not prove that a campaign link on a different hostname or market path behaves the same way. Record the intended destination with equal care.
Write down where the failure appears: an email, Google result, navigation menu, saved bookmark or external referral. Then state what happens instead of using “broken” as the description. Does the old product load, does a 404 appear, does the browser loop, or does it arrive at an unexpected language? Those observations divide the problem into very different investigations. Save the first result before editing anything so later tests have a reliable baseline.
Check whether the source is still live
Shopify’s native redirect system works with broken source URLs. If the original product or page still serves valid content, a redirect entry does not take priority over that live page. This is the first condition to check when a mapping looks correct but appears to do nothing.
Do not immediately delete the source to make the rule work. Establish why it is still live and whether it should remain available. A seasonal collection, an item awaiting replenishment or a page used by another market may have a legitimate purpose. If retirement is appropriate, coordinate the visibility change and redirect as one release. Verify both the customer outcome and any affected internal links afterwards, rather than treating deletion as a troubleshooting experiment.
Classify the response before choosing a fix
A browser screenshot shows the destination but often hides how it was reached. A developer can inspect the request in browser network tools or use a header request to see the status and Location value. Test without automatically following every hop first, then follow the chain to its final response.
| Observed result | Likely investigation | Useful next check |
|---|---|---|
| Source returns normal content | Source is active | Confirm intended retirement or preservation |
| Source returns 404 | Missing, mismatched or unsupported rule | Compare exact path and limitations |
| Redirect points to another redirect | Chain | Map directly to the final relevant destination |
| Browser reports repeated redirects | Loop or conflicting layers | Trace each hop and hostname |
| Correct redirect, wrong language | Market mapping | Test the locale-specific source and target |
| Only one browser differs | Cached response | Retest in a clean browser context |
The table narrows the next action. It does not prove a cause without checking the actual response.
Recognise paths the native tool cannot handle
Shopify reserves certain routes, and its documentation lists prefixes and fixed paths that cannot be redirected normally. Collection tag-filter paths have their own limitation. Query strings can also behave differently from a simple path mapping. A rule that works for a retired product handle may therefore be unsuitable for a filtered collection URL.
Check the current official limitations rather than copying a workaround from an old forum answer. Avoid adding a theme script solely to make the browser appear to move: a visual navigation change and a server redirect are different mechanisms. If a special case needs custom infrastructure or an app, define the requirement and verify the response it produces. Do not assume that an app can override every reserved Shopify route.
Contact StoreBuilt for a scoped review of the affected Shopify journey.
Make market paths explicit
List the locale paths customers actually use, such as the default storefront and a translated subfolder. Shopify explains that redirects do not automatically apply to every market subfolder. A successful root-path test is therefore only one row in the acceptance sheet.
For each row, check product availability, language and destination relevance. Sending a visitor to a technically valid page that cannot sell into their market is not a complete recovery. Keep tracking parameters where they are meaningful, but distinguish campaign attribution from the path used to identify the page. If a query-string-specific requirement exists, test that requirement explicitly rather than assuming a path redirect implements conditional campaign logic. Include links from old translated emails or international partner pages in the sample set.
Distinguish caching from an unchanged rule
Permanent redirects may be cached by browsers and search engines. If one browser continues to use an old destination after a change, compare it with a fresh browser context and a current network response. Repeatedly toggling the rule while looking at one cached result can create uncertainty about which version is actually live.
Keep a timestamped record of the change and test. If there is another delivery layer in front of the store, have its owner check whether it contributes a redirect or cache entry. Do not change DNS while diagnosing a path-specific problem unless the evidence points to the hostname setup. The aim is to isolate which layer made the decision, then make the smallest correction in that layer.
Choose a destination that fulfils the original intent
Consider an illustrative UK homeware shop retiring a discontinued desk lamp. A redirect to the closest compatible replacement could help a shopper who wanted that type of lamp. A redirect to the homepage leaves them to restart. If no replacement exists, an informative category may be more useful, but that choice requires a merchandising judgement.
This is an example for testing, not a claimed client result. The key check is whether the target answers why the person followed the old link. Confirm dimensions, compatibility and availability where those details matter. Avoid sending a spare-part URL to an unrelated bestselling item just because it has a high conversion rate. Technical correctness and commercial relevance should both be acceptance criteria.
Remove chains and update owned links
Once the redirect works, update navigation, editorial links and campaign templates under your control to use the final destination. Redirects remain useful for historic links, but there is little benefit in making every new internal click take an avoidable extra hop.
| Evidence field | Example entry | Why it matters |
|---|---|---|
| Source | Exact retired product path | Prevents testing a similar URL |
| Target | Final relevant replacement | Makes the intended result reviewable |
| First response | Status and Location | Shows the server decision |
| Final response | Successful page with correct content | Confirms a usable landing page |
| Locale and device | UK default, mobile browser | Captures customer context |
| Change owner | Named responsible colleague | Gives future corrections a clear route |
Keep the sheet with the release record. Export existing redirects before a bulk change so you can compare and restore mappings if needed.
Verify search signals after the repair
Check that the destination is accessible, has the intended canonical and is linked from relevant pages. Use Search Console to inspect important changed URLs when access is available. A working 301 is evidence of the technical repair; it is not proof that Google has already processed the move or that rankings will improve.
Monitor requests to the old URL and customer reports after release. A recurring 404 might reveal a second spelling, a locale path or an external link not included in the original mapping. Add only the mappings the evidence supports. Keep the broader Shopify SEO and AI search service involved when many valuable URLs or a migration are affected.
StoreBuilt point of view
A redirect problem should become smaller as evidence accumulates. Start with one exact URL, prove its status, identify the deciding layer and choose a relevant destination. That sequence prevents broad theme changes from disguising a simple eligibility or path mismatch. The best handover is a verified mapping with a short test record that another colleague can reproduce.
Related reading: Shopify url handle change governance uk.
Sources and next step
Platform guidance checked on 20 September 2026. The diagnostic examples and acceptance frameworks are StoreBuilt editorial recommendations; no client performance figures are claimed.
Contact StoreBuilt to turn the findings into a tested implementation plan.