Shopify 404 errors: when to redirect and when to leave the 404

What does Google do with a 404?

Google's documentation on how HTTP status codes affect its crawlers is short and unambiguous. It does not use content from URLs that return a 4xx status. If a URL was previously used and now returns a 4xx, Google stops using it over time; a URL that is already indexed is removed from the index; and newly encountered 404 pages are not processed. The same page says every 4xx apart from 429 is treated the same way, so a 404 and a 410 are read as the same signal, "the content doesn't exist", and crawling of the address gradually decreases.

Two practical points follow. First, a 404 for a product you retired is not an SEO problem to be eliminated; it is how the web says "gone", and Google handles it. Second, the cost of a 404 is not in the index but in the visit: someone follows an old link, a bookmark or an old ad, and lands on an error. That is where a redirect earns its place, and where it should be used with some thought.

When should a removed URL be redirected, and when left alone?

Google's redirects guide lists "you removed a page and you want to send users to a new page" among the reasons to redirect. The condition is the new page. A redirect is a statement that the destination is where the old content now lives, so we apply three tests.

The middle row is a judgement call, and the home page is rarely the right answer. A redirect to a page that does not match what the visitor asked for sends them to something they did not want; leaving the 404 and giving them a useful 404 page is more honest.

Redirect permanently when you are sure the change will not be reverted. Google treats 301 and 308 as a strong signal that the target should be the canonical one, whereas a 302 is a weak signal and a 307 is equivalent to it. The redirects guide recommends a permanent server-side redirect whenever the URL shown in results should change.

How do you create redirects in Shopify?

A Shopify redirect has two fields, a path (the old address) and a target (where the visitor goes). In the Admin API this is the UrlRedirect object: path is the old path to be redirected from and target the location the visitor lands on. Reading redirects needs the read_online_store_navigation access scope, and creating them goes through urlRedirectCreate, which needs write_online_store_navigation. The input is just the two fields:

{
  "urlRedirect": {
    "path": "/old-handle",
    "target": "/new-handle"
  }
}

For a handful of URLs, the redirect list in the admin is enough. For a migration or a catalogue clean-up with hundreds of old addresses, build the list in a spreadsheet first, map each old path to its final destination, and import or script it in one pass. Our migration checklist covers building that map before launch.

Use relative paths for path and target as in the example, and keep the target to a page that returns 200 on its own.

Why do redirect chains matter?

Google follows up to 10 redirect hops by default for general web content, so a short chain will still resolve. We still flatten them. A chain forms when /a redirects to /b and /b was later redirected to /c: the sensible fix is to edit the first redirect so that /a goes straight to /c. It keeps each address one hop from its destination, so a later change cannot silently push a visitor past the limit. Google's own inspection tooling does not follow redirects at all, so a check run through that tool alone will not show you where a chain ends.

To find chains, list your redirects, then check whether any target is also the path of another redirect. A spreadsheet lookup does it in a minute.

What is a soft 404, and why is a redirect the wrong fix?

The status codes page defines the case: if a server answers 2xx but the content suggests an error, such as an empty page or an error message, Search Console reports a soft 404. The URL was served successfully as far as HTTP is concerned, while the page tells the visitor that nothing is there.

On a Shopify store the usual sources are:

• An empty collection that still returns 200 and renders a "no products found" message, for example after every product in it has been sold out and hidden.
• A page or article that was cleared of content but not deleted.
• A search or filter result with no matches, which belongs to the family of URLs we discuss in the collection filter guide.

The fix depends on the case. If the page is genuinely gone, remove it, so that it returns a real 404 status, or redirect it if a close replacement exists. If it should exist, put content on it. If it is a temporary state, such as a seasonal collection, keeping it with a link to related collections is a decision to make deliberately, because while it is empty Google may report it as a soft 404. We do not redirect an empty seasonal collection to the home page: the visitor who followed a link to it learns nothing, and the signal sent to Google is wrong.

What should the 404 page itself do?

Shopify's 404 template documentation says the template should make it clear that the page could not be found, and should offer obvious ways to carry on: links to popular pages, a search bar, or a link to the home page or a collection. It lives at templates/404.json in the theme, and because it is a JSON template, any HTML or Liquid has to live in a section the template references. Dawn's implementation is a good baseline to compare your theme with.

Check yours in a minute: open an address that does not exist, such as your domain followed by a random string, and look at what the page offers. A page that says only "404" with a single button is leaving traffic on the table, while a page that returns a 200 would put you back in soft 404 territory, so confirm the status in your browser's network panel or with a header request.

How do you find the 404s that matter?

1. Search Console, Page indexing report. Open the "Not found (404)" reason. It lists URLs Google tried and found missing.
2. Check which have a replacement. For each URL, ask whether a current page serves the same intent. Those get a redirect.
3. Ignore the rest. Old tracking URLs, mistyped links from other sites and addresses that never held content do not need action.
4. Look for internal links first. If one of your own pages links to a missing URL, update the link rather than redirecting it. A redirect on an internal link is a patch; the link is the defect. Our sitemap guide explains why the sitemap should never list a URL that redirects or returns a 404.
5. Re-check after a few weeks. The reported number should fall as Google drops the URLs; it does not need to reach zero.

What should you fix first, and how long does it take?

1. Open the Not found (404) list in Search Console and mark each URL as "has a close replacement" or "does not" (thirty minutes for a typical store).
2. Create permanent redirects for the first group, pointing each straight to its final page (about an hour for a few dozen URLs, a day for a full catalogue map).
3. Fix internal links that point at missing URLs (an hour).
4. Load a made-up address and confirm the 404 page returns a 404 status and offers a route onward (five minutes).
5. Review empty collections and cleared pages for soft 404s (thirty minutes).

If you would rather have the 404s, redirects and soft 404s checked against a crawl of the whole store, that is covered in our Store Teardown, and the wider services page shows how we work on catalogue and migration clean-ups.