On This Page
When we started building redirect support in DataJelly, we thought it would be simple. "Just return a 301 and call it done." That assumption lasted about a day.
What we actually ended up building was a full redirect system — spanning edge networking, transport-level validation, SEO auditing, management tooling, and documentation. This post breaks down how we built it, step by step.
The Problem: Redirects Are Simple… Until They Aren't
Redirects sit at the intersection of networking (HTTP behavior), infrastructure (CDNs, proxies, DNS), SEO (Google expectations), and application logic (routing). Most platforms treat redirects as a config file or an afterthought.
But for DataJelly, redirects had to work at the edge, for bots and humans, with zero origin changes, and be verifiable and testable. That last part turned out to be the hardest.
Step 1: Research — What "Correct" Actually Means
Before writing code, we had to answer: What is a "correct" redirect? We validated behavior across Googlebot expectations, browser handling, common SEO tools (Ahrefs, Screaming Frog), and platform behavior (Vercel, Netlify, Cloudflare).
Key Findings
- 301 vs 302 matters less than correctness
- Redirect chains are bad (performance + SEO)
- Loops must be prevented
- Query strings must be preserved
- Trailing slash normalization is critical
Most importantly: if you don't emit a real HTTP redirect, SEO tools will not detect it. This forced us to commit to true HTTP redirects at the edge — not rewrites.
Tech Stack (for this feature)
| Layer | Technology | Purpose |
|---|---|---|
| Edge Routing | Node.js (Fastify) | Evaluate redirect rules and return HTTP 301 responses at the edge |
| Proxy / Transport | Node.js | Handle upstream requests, TLS/SNI, and fallback behavior |
| Data / Config | PostgreSQL | Store domain mappings and redirect rules |
| Cache Layer | Redis | Store snapshot and bot cache (used outside redirect path) |
| Frontend / UI | Lovable.dev | Dashboard for managing and importing redirect rules |
| Audit Tool | Node + Fetch | Crawl sites and detect redirects using manual HTTP handling |
Step 2: Core System — Edge Redirect Engine
The foundation lives in our edge proxy. Every request flows through a redirect evaluation pipeline before reaching the origin.
Browser / Bot
→ DataJelly Edge
→ Redirect Evaluation
→ Response
/flock1 → /flock2
301 Location: /flock2
Why Edge Matters
Traditional redirects happen at the origin — requiring deploys, adding latency, and creating inconsistencies. DataJelly redirects execute at the edge: instant, centralized, and consistent for bots and users alike.
Step 3: Transport Layer Testing (The Hard Lesson)
At first, everything looked correct. But our audit tool said: "No redirects found."
The issue: most HTTP clients (including fetch) automatically follow redirects. Instead of seeing 301 → /flock2, we saw 200 → /flock2 — which made it look like no redirect happened.
The Fix
fetch(url, { redirect: 'manual' })
Explicitly disabling redirect following exposed the real behavior: 301 → Location: /flock2
Takeaway: Testing redirects requires transport-level control, not just HTTP requests. This became the foundation of our audit system.
Step 4: Content Layer Testing — Building the SEO Audit Tool
Once we could detect redirects correctly, we built a crawler to answer: "Are my redirects actually good?"
The Tool
- Crawls pages (sitemap + links)
- Detects all redirect responses
- Follows chains manually
- Tracks status codes, destinations, hop counts, and broken paths
/flock-chain1
→ /flock-chain2
→ /flock-final
Hops: 2 · Type: Chain
The redirect audit tool crawling a live site:
This turns redirects from "configured" into "validated."
Step 5: Management Layer — The Dashboard
Once redirects worked and were testable, we built the management UI.
Features
- Add/edit redirects with instant edge deployment
- Bulk import via CSV
- Validation: no loops, no duplicates, relative paths only
Design goal: simple enough for non-engineers, safe enough to prevent mistakes, fast enough to apply instantly.
The redirect management dashboard in action:
Step 6: Documentation — Making It Understandable
This is where most systems fail. We didn't just ship a feature — we built a guide system around it. The guide explains why redirects matter for SEO, common use cases, best practices, how DataJelly works, and how to test redirects.
The Key Addition: Test Pages
We created a live testing environment where users can verify behavior instantly:
/flock1→ basic redirect/flock-query→ query preservation/flock-chain1→ multi-hop chain/flock-loop1→ loop detection
What We Ended Up With
This is what we thought we were building: a redirect feature.
This is what we actually built: a full redirect system.
The Bigger Insight
Redirects are not just "URL → URL". They are a core part of how search engines understand your site. If they're wrong, SEO suffers, crawlers get confused, and performance drops. If they're right, everything downstream improves.
What's Next
We're now working on Redirect Health Scoring:
- Detect chains and loops automatically
- Flag bad patterns
- Provide actionable fixes
Final Thought
"The biggest surprise building this feature was: redirects aren't hard — understanding and validating them is."
That's the gap DataJelly is closing.