DEV Community: Rahib Ali

Redirect chains are silently slowing your site — here's how to find and fix them

Rahib Ali — Fri, 23 Oct 2026 05:18:00 +0000

You paste a URL into your browser. The page loads. Everything looks fine — but between your click and that final render, the browser may have silently hopped through two, three, or five redirects: http to https, bare domain to www, old path to new path, a trailing slash added along the way.

Browsers never show you this. They follow every hop automatically and render the destination. Redirect chains are invisible by design — and that is exactly why they quietly grow into a real problem.

Why a chain of redirects hurts

Latency. Every 301 or 302 is a full extra HTTP round trip: DNS, TLS handshake, request, response. One hop is noise. Four hops on a mobile connection is a noticeable delay before the first byte of the real page.

Crawl efficiency. Googlebot follows redirect chains, but it gives up after about 10 hops. A page that is only reachable through a long chain gets crawled less often — and Google's own documentation warns against chaining redirects where you can avoid it.

Link equity and canonicalization. A permanent move should be one clean 301 straight to the final URL. When old backlinks point at URL A, which 301s to B, which 302s to C, you are leaking both speed and signal at every step.

Search Console noise. "Page with redirect" and "Redirect error" reports are usually a chain problem, not a single-redirect problem.

See the chain: curl

The fastest honest view of a chain is in your terminal:

curl -IL https://example.com/old-page

-I fetches headers only, -L follows redirects. The output shows every hop — status code plus the Location header it points to:

HTTP/2 301
location: https://example.com/new-page

HTTP/2 302
location: https://example.com/new-page/

HTTP/2 200

That second hop is a 302 sending a permanent move to a trailing-slash variant — two separate mistakes visible in ten seconds of terminal output.

See the chain: DevTools

In Chrome or Firefox DevTools, open the Network tab, tick "Preserve log", and reload. Every request in the chain appears with its status code. This is the best option when you suspect client-side (meta refresh or JavaScript) redirects, which curl won't reveal — but it's tedious if you need to check more than a couple of URLs.

Trace chains in bulk: a tiny Node script

When a migration leaves you with hundreds of legacy URLs, clicking through each one isn't an option. This script follows a chain one hop at a time and prints it — using node:http/node:https directly, because fetch can't do this job: even with redirect: 'manual' it hands back an opaque redirect response (status 0, headers unreadable). Raw HTTP requests have no such filter:

// trace.mjs — usage: node trace.mjs https://example.com/old-page
// Zero dependencies. http.get / https.get never follow redirects,
// so each hop's real status code and Location header stay visible.
import http from 'node:http';
import https from 'node:https';

const get = (url) => new Promise((resolve, reject) => {
  const mod = url.startsWith('https:') ? https : http;
  mod.get(url, { headers: { 'User-Agent': 'redirect-tracer/1.0' } }, (res) => {
    res.resume(); // discard the body, we only need headers
    resolve({ status: res.statusCode, location: res.headers.location });
  }).on('error', reject);
});

let current = process.argv[2];

for (let hop = 1; hop <= 10; hop++) {
  const { status, location } = await get(current);
  const next = location ? new URL(location, current).href : null;

  console.log(`hop ${hop}: ${status}  ${current}${next ? `\n      → ${next}` : ''}`);

  if (!next || status < 300 || status > 399) break;
  if (hop === 10) { console.log('chain too long — stopping'); break; }
  current = next;
}

Run it against a list of URLs from your sitemap or backlink export and you'll have a full chain audit in minutes. (MDN's guide to HTTP redirections has the full reference on status-code semantics if you want the details.)

The chains I keep finding in the wild

1. The protocol + host stack. http://example.com → https://example.com → https://www.example.com. Two hops before the site even starts loading. Fix: every variant should 301 straight to the canonical URL in a single hop.

2. Trailing-slash ping-pong. /page → /page/ → /page — usually two CMS rules fighting each other. Pick one canonical form and enforce it once.

3. Migration leftovers. old-domain.com/page → new-domain.com/page → new-domain.com/renamed-page → 200. Every legacy backlink pays three hops forever. Point the old URLs directly at their final destinations.

4. The accidental 302. A permanent move shipped as a 302 or 307 because it was the framework's default. Search engines keep indexing the old URL and never fully transfer the signal. If the move is permanent, it must be a 301.

5. Redirect loops. A → B → A, and the browser gives up with ERR_TOO_MANY_REDIRECTS. Almost always two conflicting rules — a www-forcing rule plus a non-www-forcing rule, or an http→https rule fighting an https→http one.

6. Chains ending in errors. The chain "works" in the browser but lands on a 404 or 500. Always check what the final hop returns, not just that the chain resolves.

A debugging workflow that actually works

Trace the full chain — curl -IL for one-offs, the script above for bulk. When I want a quick visual answer without the terminal, I paste the URL into this free redirect chain checker, which follows every hop server-side and lists each status code and destination, with loop detection.
Count the hops. More than two to reach the final page is worth flattening.
Read the status codes. Permanent moves must be 301 — a 302/307 in the middle is a bug, not a preference.
Verify the destination. Confirm the final URL returns 200 and isn't carrying a surprise noindex.
Fix at the source. Point the original URL straight at the final destination, and update internal links, canonical tags, and sitemaps to skip the chain entirely. Redirecting to a URL that already redirects is how chains grow — one "quick fix" at a time.

Redirect chains accumulate because nothing complains about them: the browser hides them, users tolerate one extra hop, and each individual redirect looks harmless in isolation. Audit them after every migration, and spot-check your most-linked pages once in a while. The fix is almost always the same — one clean 301, straight to the destination.

Stop Hand-Writing JSON-LD: Generate Valid Schema Markup in Seconds

Rahib Ali — Sun, 04 Oct 2026 13:06:31 +0000

If you've ever hand-written JSON-LD structured data, you know the drill: one missing comma, one wrong @type, and Google silently ignores your rich results. I build SEO tools for a living, and I still don't write schema by hand anymore. Here's why — and the workflow I use instead.

Why hand-written JSON-LD breaks

JSON-LD looks simple until it isn't. The classic failure modes:

Trailing commas — valid in JS, fatal in JSON.
Wrong nesting — geo inside location vs. parallel to it for LocalBusiness.
Missing required fields — Google needs headline, author, datePublished, and image for Article. Miss one and you get no rich result, no error message, just silence.
Unescaped characters — quotes inside descriptions breaking the whole block.

The 30-second workflow

For standard schema types, a generator beats hand-writing every time. I built a free JSON-LD schema generator at FrostRank — no signup, runs entirely in your browser.

Pick the type (Article, FAQPage, Product, LocalBusiness, Organization, BreadcrumbList, Person…), fill in the fields, copy the output. It comes wrapped in <script type="application/ld+json">, ready to paste into your page.

Example output for an Organization:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Inc",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://twitter.com/example",
    "https://linkedin.com/company/example"
  ]
}

Drop it in your <head>:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Inc"
}
</script>

Always validate before you ship

Generated or not, validate everything:

Google's Rich Results Test (https://search.google.com/test/rich-results) — paste the URL or code snippet; it flags errors and confirms rich-result eligibility.
Schema Markup Validator (https://validator.schema.org/) — checks your markup against the schema.org spec itself.

If the Rich Results Test shows errors, fix the fields and regenerate — don't patch the JSON by hand and reintroduce the exact mistakes the generator saved you from.

When you SHOULD write it by hand

Generators cover the standard types. Reach for hand-written JSON-LD when:

You're combining multiple entities with @graph
You need dynamic schema injected at runtime (e.g., a product price pulled from your DB)
You're doing something exotic, like HowTo with video clips

Even then, generate the skeleton first and extend it. Starting from valid markup beats starting from a blank file.

TL;DR

Don't hand-write boilerplate schema — generate it.
Validate with Google's Rich Results Test before deploying.
Keep a generator bookmarked for the next time someone says "can you add FAQ schema to this page?"

Try the free JSON-LD schema generator — it's client-side, so nothing you paste ever leaves your tab. What's your schema workflow — generator, plugin, or hand-rolled?