Are your URLs answering directly, over HTTPS?

Redirects are invisible in the browser but real to a crawler: every hop costs time and dilutes the signal you meant to send. And a site that still answers on plain HTTP serves two versions of every page.

Checks whether HTTP redirects to HTTPS and whether a set of your own URLs redirect. Saved to your account if you are signed in to a paid plan.

How this check works

Shipwork requests your site over plain HTTP to see whether it redirects to HTTPS, and requests a set of your own URLs without following redirects, so it can see each hop. URLs that redirect should be listed at their final address instead.

What the redirect check tests

This site-wide check first requests the HTTP version of your home page without automatically following redirects. It reports whether HTTP redirects to HTTPS or serves content directly. It also checks up to four discovered pages without following redirects, so it can identify sampled URLs that point somewhere else rather than returning their page directly.

The report is a bounded sample. It does not accept an arbitrary list of URLs or trace every redirect hop for every page. A result about the HTTP homepage is different from a redirect found on a product or content URL. Use a dedicated URL-by-URL redirect tester when you need every hop for a particular address.

Whether the site’s HTTP homepage redirects to HTTPS.
Whether it serves content over plain HTTP without redirecting.
Redirect responses on up to four sampled site pages.
Whether a sampled redirect is a same-path host normalization or a move to another path.

How to read redirect results

A single HTTP-to-HTTPS redirect is a normal way to send visitors to the secure version. A sampled page that redirects to its final URL may still work, but internal links and sitemap entries should generally name the final URL directly. Multiple separate rules can create a chain—for example, HTTP to HTTPS, then apex to www, then an old path to a new path. The check’s findings help locate redirects; inspect the full chain separately when you need to count every hop.

A loop prevents the destination from loading. A redirect to an unrelated page can also be misleading: sending a deleted product to a generic home page does not preserve the original content. Search engines may treat irrelevant redirects as soft 404 behavior. Fix the rule or link at its source, then verify the target directly.

Keep one consistent preferred host and HTTPS destination.
Update links and sitemap entries to final URLs, not addresses that redirect.
Redirect removed content only to a genuinely equivalent replacement.

Flatten chains and correct destinations

List the exact source URL, each Location response and the final destination. Check platform URL settings, CDN rules and server configuration for overlapping host or path rewrites. Choose one canonical host, then make each old URL point directly to the final equivalent page. Avoid adding a second redirect rule before confirming how the existing rules interact.

For example, a request that goes from http://example.com/old-product to https://www.example.com/old-product and then to https://www.example.com/products/blue-shirt should ideally be changed so the old address goes straight to the final product URL. Keep permanent redirects for lasting URL changes and temporary redirects only when the move is temporary and supported by the platform.

Test HTTP, HTTPS, www and apex variants of the same important URL.
Update internal links and feeds to the final destination after a migration.
Use the redirect generator to prepare rules, then verify them on the live host.
See the redirect chain guide for migration cases.

When to run a redirect check

Run it after a domain migration, changing HTTPS or www settings, changing URL handles, or installing a redirect app. It can catch an HTTP homepage that still serves content and sampled internal pages that point through redirects. If a specific Google or Merchant Center URL is failing, test that exact address and compare its destination with the product or page users expect.

A redirect is not automatically bad. It is often the right way to preserve access after a permanent URL move. The goal is a direct and relevant path to a working page, with internal links and sitemaps using the final address.

Broken links check: internal links that return dead-page or server errors.
Canonical check: preferred URLs in page markup.
Sitemap check: entries that may still point at redirected URLs.

Questions

Why does HTTPS matter for SEO?

HTTPS is a confirmed ranking signal and a trust factor, and serving both HTTP and HTTPS creates two versions of every page.

Do redirects hurt ranking?

A single permanent redirect passes signals, but chains and loops waste crawl budget and can lose equity along the way.

Should sitemap URLs ever redirect?

No. A sitemap should list final URLs. Redirecting entries waste the crawl budget the sitemap exists to save.

How do I check where a URL redirects?

Request the URL without automatically following redirects, read its Location header, then request that destination and repeat until it returns a final response. Shipwork’s site-wide redirect check tests the HTTP homepage and up to four sampled pages; it does not trace every hop for every URL. Use a dedicated URL-level redirect tool for a specific complete chain.

Are redirects bad for SEO?

No. Redirects are useful when a URL permanently moves and the destination is equivalent. Problems arise when chains add unnecessary steps, loops prevent access, or unrelated destinations replace the original content. Update links and sitemap entries to the final URL where possible. Test important legacy addresses after migrations to confirm they reach the correct live page.

Should I redirect HTTP to HTTPS?

If your site is intended to use HTTPS, redirect HTTP requests to the HTTPS version and choose one preferred host. Check that redirects do not bounce between www and apex or add multiple path rewrites. Also ensure internal links, canonicals and sitemaps consistently use the HTTPS destination.

How many redirects are too many?

There is no single number that makes every redirect invalid, but avoid unnecessary hops. Each hop adds another request and can make crawling slower or less reliable. Point old URLs directly to their final relevant destination where practical. A site-wide sampled check can flag redirects; inspect a specific URL’s full chain to see exactly how many hops it takes.

Can I redirect a deleted product to my home page?

Usually that is a poor destination because the homepage does not replace the deleted product. Search engines and shoppers may treat an unrelated redirect as a soft 404. If a genuinely equivalent replacement exists, redirect to it. Otherwise return an appropriate not-found response and remove the old URL from feeds, sitemaps and internal links.

Keep reading

What this reads

Reads public pages from outside your network, the way a crawler does.
No signup, and nothing is stored on the free checks.
One of 83 checks across discovery, content, markup, trust and catalogue data.

83checks

0signups needed

0stored on free checks

Cool, just ran an audit and got some insights! Let’s see if I can fix them :)

Tenta Dev, @DevTenta

Whoah! this site is crazy, nothing to roast at all

Ainreek, @AinreekAI

cool as heck, tried it on my blog and the insights it gave are helpful and not bluff.

Refaat 🍉 (Mouse), @1Mouse__