DEV Community: Redirhub

How to Preserve UTM Parameters Through Redirects Without Losing Attribution

Redirhub — Fri, 14 Aug 2026 13:53:03 +0000

How to Preserve UTM Parameters Through Redirects Without Losing Attribution

A practical guide to forwarding campaign query strings through redirects, testing every hop, and keeping GA4 attribution useful.

You can build a clean campaign URL and still lose attribution before the visitor reaches the landing page.

The usual culprit is not GA4, the ad platform, or the frontend tag. It is a redirect that sends the browser to the right page while quietly dropping the query string.

This matters for developers because redirects often live in infrastructure: Nginx, Apache, edge middleware, short-link tools, CMS routing, or application code. If one hop in the chain forgets ?utm_source=..., the final page cannot recover it.

This guide walks through redirect patterns that preserve UTM parameters without creating duplicate keys, unsafe destinations, or analytics noise.

The Failure Mode

Start with a tagged campaign URL:

https://go.example.com/spring-sale?utm_source=linkedin&utm_medium=social&utm_campaign=spring_sale

A broken redirect might return:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/spring-sale

The redirect is valid HTTP. The user lands on the right page. But the destination URL no longer contains utm_source, utm_medium, or utm_campaign, so GA4 sees a pageview without the campaign context you expected.

The correct redirect preserves the query string:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/spring-sale?utm_source=linkedin&utm_medium=social&utm_campaign=spring_sale

Status code correctness and attribution correctness are separate checks. A 301, 302, 307, or 308 can all preserve or drop parameters depending on how the Location header is built.

Choose the Redirect Type First

Use a permanent redirect such as 301 or 308 when the source URL has permanently moved. Use a temporary redirect such as 302 or 307 for short-lived campaigns, experiments, or links whose destination may change.

Do not use a permanent redirect just because it works in a quick test. Browsers, crawlers, and intermediate systems may cache permanent redirects, which makes later campaign changes harder to reason about.

The query-forwarding rule should be intentional either way: if the campaign URL arrives with tracking parameters, every redirect hop that owns the route should preserve them.

Server Examples

Nginx

For a destination with no existing query string, append the incoming query safely with $is_args$args:

location = /spring {
    return 302 https://www.example.com/spring-sale$is_args$args;
}

$is_args expands to ? only when the incoming request has a query string. $args contains the raw incoming query string. That avoids producing a trailing ? for untagged visits.

If the destination already has parameters, do not add a second question mark:

location = /spring {
    return 302 https://www.example.com/spring-sale?region=us&$args;
}

That simple version is fine only if you have tested the empty-query case and accept the trailing &. For stricter output, split tagged and untagged cases or move the logic into application/edge code where URL parsing is clearer.

Apache

With mod_rewrite, QSA appends the original query string to the replacement URL:

RewriteEngine On
RewriteRule ^spring$ https://www.example.com/spring-sale [R=302,L,NE,QSA]

QSA means query string append. It is especially important when the replacement URL includes its own query string, because without explicit handling the original parameters may be replaced.

Application Code

In application code, parse URLs instead of concatenating strings:

app.get("/spring", (req, res) => {
  const incoming = new URL(req.originalUrl, "https://go.example.com");
  const destination = new URL("https://www.example.com/spring-sale");

  incoming.searchParams.forEach((value, key) => {
    destination.searchParams.append(key, value);
  });

  res.redirect(302, destination.toString());
});

This preserves duplicate keys exactly as received. If you prefer one value per UTM key, use set() for known campaign keys instead of append():

for (const key of ["utm_source", "utm_medium", "utm_campaign", "utm_content", "utm_term"]) {
  const value = incoming.searchParams.get(key);
  if (value) destination.searchParams.set(key, value);
}

The important part is that URL encoding is handled by URL and URLSearchParams. Do not build redirect URLs by stitching raw request values into a string.

Decide Your Duplicate-Key Policy

Duplicate parameters are easy to create:

https://www.example.com/spring-sale?utm_source=newsletter&utm_source=linkedin

Different tools may choose the first value, the last value, or expose both. That ambiguity is bad for attribution.

Pick a policy before launch:

Source-owned UTMs win: the incoming campaign parameters replace destination defaults.
Destination-owned UTMs win: the landing page keeps its predefined campaign values.
Reject duplicates: the redirect refuses or normalizes links with conflicting campaign keys.

For most campaign redirects, source-owned UTMs are easiest to reason about because the distributed URL defines the campaign. There are exceptions, especially when a destination uses query parameters for product filters, locales, or experiments.

Multi-Hop Redirects

Campaign links often pass through several systems:

ad platform -> short link -> branded redirect domain -> landing page

Attribution survives only if every hop preserves the query string. If the short link keeps the parameters but the branded redirect drops them, the final page still loses.

Trace the whole chain:

curl -sSIL \
  'https://go.example.com/spring?utm_source=linkedin&utm_medium=social&utm_campaign=spring_sale'

Read every Location header. Confirm:

The expected number of redirects occurs.
Each hop stays on an expected hostname.
HTTPS does not downgrade to HTTP.
Required UTM parameters are still present.
Existing destination parameters are merged intentionally.
Duplicate UTM keys are absent or match your policy.

To follow the redirect chain and limit loops:

curl -sSIL -L --max-redirs 10 \
  'https://go.example.com/spring?utm_source=linkedin&utm_medium=social&utm_campaign=spring_sale'

An unexpectedly long chain is not just inefficient. It increases the chance that one system will strip or rewrite parameters.

Open-Redirect Safety

Avoid patterns like this:

res.redirect(req.query.next);

That can turn a tracking route into an open redirect, where an attacker sends users through your domain to a malicious site.

Use an allowlist for destinations:

const allowedDestinations = {
  spring: "https://www.example.com/spring-sale",
  pricing: "https://www.example.com/pricing"
};

const target = allowedDestinations[req.params.slug];
if (!target) return res.sendStatus(404);

const destination = new URL(target);

Then copy only the parameters you intend to support. Many teams preserve utm_*, gclid, fbclid, and a few product parameters while rejecting unrelated keys. The right list depends on your analytics and privacy requirements.

Production Checklist

Before a campaign goes live, test these cases:

/spring?utm_source=linkedin&utm_medium=social&utm_campaign=spring_sale
/spring?utm_source=newsletter
/spring
/spring?utm_campaign=spring%20sale
/spring?utm_source=one&utm_source=two

Verify at two layers.

First, inspect network behavior with curl or browser developer tools. The final URL should contain the expected parameters, encoded correctly, with no surprise hostnames or loops.

Second, test the analytics result. In GA4 DebugView or realtime reports, confirm the visit is attributed to the expected source, medium, and campaign. A correct final URL is necessary, but analytics configuration can still affect what appears in reports.

Managing Redirects at Scale

A few hand-written rules are easy to audit. Hundreds of campaign routes, vanity domains, migration URLs, and partner links need a process.

Treat redirects as managed configuration:

Store source URL, destination URL, status code, owner, and query-forwarding policy.
Test representative tagged and untagged URLs after bulk changes.
Monitor failed destinations, redirect loops, and unexpected hostnames.
Keep campaign links stable even when the landing page changes.
Document whether utm_*, ad click IDs, and product parameters are forwarded.

If you use a redirect management platform, verify query forwarding explicitly. Do not assume every tool preserves parameters by default. For a deeper walkthrough, see this guide on how to preserve UTM parameters through redirects.

The QR Code Was Printed. The Landing Page Was Wrong. Here’s the Recovery Plan.

Redirhub — Mon, 27 Jul 2026 15:41:07 +0000

The QR Code Was Never the Real Problem

A QR code can be perfectly generated, printed at high resolution, and placed in exactly the right location—and still become a liability a few weeks later.

The problem usually appears after distribution:

The campaign landing page expires.
The event registration URL changes.
A product page is moved during a website migration.
Tracking parameters were missing from the original link.
A printed menu, poster, package, or sign has already been distributed.

At that point, the QR image is not easy to change. The physical asset may be in stores, on packaging, in public spaces, or in the hands of customers. Reprinting everything is expensive or impossible.

The useful question is not:

“How do I generate a QR code?”

It is:

“Where can I regain control after the QR code has already been distributed?”

Static QR Codes vs. Dynamic Destinations

A static QR code encodes the final destination directly. When someone scans it, the device opens that URL.

That simplicity is also the limitation. If the destination changes, the QR code does not know about the new location. Every physical copy still points to the old URL.

A more resilient design inserts a redirect layer:

QR code → stable short URL → redirect rule → current destination

The QR code does not need to change. The stable URL remains the control point, while the redirect rule determines where visitors go today.

This is what people usually mean when they talk about a dynamic QR code. The image itself is not necessarily changing. The destination behind it is configurable.

A Recovery Scenario

Imagine a team prints 5,000 event cards. Each card contains a QR code leading to:

https://go.example.com/spring-event

Two days before the event, the organizer changes the registration system. The old destination now returns a 404 page.

Without an intermediate redirect, the options are unpleasant:

Reprint and redistribute the cards.
Ask visitors to manually find the new registration page.
Keep the old page alive and add another layer of instructions.
Accept that some scans will fail.

With a redirect layer, the recovery is smaller:

Keep the stable URL unchanged.
Update its destination to the new registration URL.
Test the QR code on multiple devices.
Monitor scans and errors after the change.

The printed asset remains valid because the stable URL remains valid.

The Engineering Requirements

A useful dynamic QR workflow needs more than a QR image generator. It needs a few operational properties.

1. A Stable Control Point

The QR code should point to a URL your team controls.

Avoid encoding a temporary campaign page, third-party form, or vendor URL directly into the image unless you are comfortable losing control when that service changes.

The physical QR code may remain in circulation for months or years. The URL behind it should therefore be treated as an infrastructure component, not disposable campaign copy.

2. Editable Destinations

The destination must be changeable without changing the QR code.

This is the central capability of the design. If changing the destination requires generating and distributing a new image, the system is still effectively static.

3. Correct Redirect Behavior

The redirect layer should support the status and path behavior your use case requires.

For a temporary campaign, a temporary redirect may be appropriate. For a permanent migration, a permanent redirect may be the better fit.

The important point is to make that decision explicitly rather than letting every campaign use the same default behavior.

4. Tracking Without Breaking the Destination

Campaign owners often discover after printing that they need attribution.

A redirect layer can preserve or add query parameters, such as UTM values, before sending the visitor to the final page.

That makes it possible to measure the campaign without changing the printed QR asset. It also gives the team one place to review how tracking is applied across different campaigns.

5. Testing and Observability

Before distribution, scan the code from several devices and networks.

After distribution, monitor whether the URL is responding, whether the destination is healthy, and whether scans are arriving as expected.

A QR code that “looks right” is not proof that the complete request path works.

The full path needs to be tested:

camera → QR decoding → stable URL → redirect response → final page

A failure at any point can make the campaign appear broken to the visitor.

Where RedirHub Fits

You can build this control layer inside your own application. That may be the right choice when your team needs custom business logic, deep integration with an existing campaign platform, or complete ownership of the routing service.

The alternative is to use a managed redirect layer for the part that is easy to underestimate: keeping stable URLs, destinations, DNS, HTTPS, and link-level visibility working together.

RedirHub provides QR code generation for links, short links with custom slugs, redirect management, per-link analytics, automated HTTPS, and API access.

In this workflow, the QR code points to a stable RedirHub-managed URL. If the campaign destination changes, the redirect record can be updated while the printed QR asset stays the same.

That does not remove the need for good campaign operations. You still need to choose the right destination, test changes, manage access, and decide how long the link should remain active.

The platform simply gives the team a durable control point instead of forcing the physical QR code to carry the entire burden.

A Safer Change Procedure

Treat destination changes like a small production change, not a casual copy-and-paste operation.

Before changing a live QR destination:

Record the current destination.
Confirm the new destination with the campaign owner.
Check that the new page loads over HTTPS.
Verify that important paths and query parameters behave correctly.
Update the redirect rule.
Scan the QR code from a real device.
Check the redirect response and final page.
Watch analytics and link health after the change.

For high-volume campaigns, add an approval step and keep a change history.

A stable URL is valuable precisely because many people may depend on it.

The Broader Lesson

Printed assets are difficult to update. Digital destinations are easy to update.

A robust QR workflow puts the boundary between those two worlds in the right place.

The QR image should be a durable entry point. The redirect layer should be the flexible control plane.

Once you think about QR codes this way, the same architecture applies to:

Packaging that outlives a product campaign
Restaurant menus that change seasonally
Conference signage and event badges
Printed documentation and manuals
Offline advertisements with changing offers
Product inserts shipped across multiple markets

The goal is not to make the QR code more complicated.

It is to avoid giving a permanent physical object responsibility for a temporary digital destination.

If a QR code has already been printed and the page behind it is wrong, do not start by replacing the image.

First, check whether you can recover the stable URL behind it.

That control point may be the difference between a minor routing change and a full reprint.

Your Redirect Domain Is Infrastructure: What the t.me Outage Teaches Us

Redirhub — Sat, 18 Jul 2026 20:01:48 +0000

A redirect domain looks small until people depend on it.

In July 2026, Telegram's t.me domain stopped resolving after the .me registry placed it on serverHold. Links such as t.me/username and t.me/channelname stopped working. Telegram's application was still running. The failure happened below the application layer, where the domain, registry, and DNS path meet.

The domain returned the following day. DomainME said the hold was related to OFAC compliance. Reporting from TechCrunch connected the timing to a U.S. Treasury sanctions listing that contained a t.me address pointing to a sanctioned VPN provider's Telegram group. That explanation is reported by the cited sources; we are not presenting it as an independently verified RedirHub finding.

The operational lesson is broader than Telegram:

If a link is important enough to publish, print, embed, or build into software, its domain is infrastructure.

The redirect is a chain, not a single rule

When someone clicks a redirect, several systems must work in sequence:

The device resolves the domain through DNS.
The domain reaches the edge or origin.
The redirect service matches the rule.
The service returns an HTTP response.
The browser follows the destination.

A failure in an earlier layer prevents the later layers from helping. A correct redirect rule cannot repair a domain that no longer resolves. A healthy destination cannot help if TLS fails before the request reaches the redirect service.

That is why "the redirect is broken" is not a diagnosis. The first useful question is: which layer failed?

Check the path in order:

Domain and DNS: Does the hostname resolve from more than one network?
TLS: Is the certificate valid and being served for the expected hostname?
Edge: Does the request reach the redirect provider?
Rule: Does the source path match the intended record?
Destination: Does the final URL return the expected response?
Policy or registry: Has the domain, account, or namespace been restricted?

Each layer has a different owner and a different recovery path. Treating them as one undifferentiated "link problem" wastes the first minutes of an incident.

One namespace can create a large blast radius

A shared redirect domain is convenient: one recognizable domain, many links, one operating model. It also creates concentration risk.

If that namespace becomes unavailable, the failure can reach every place where it appears:

Campaign URLs
Documentation
Printed QR codes
Partner links
Support articles
App deep links
Social posts

The more widely a domain is used, the more carefully its dependency should be managed. This applies to company-owned redirect domains, short-link providers, campaign platforms, and internal routing services—not only to Telegram.

The risk is often invisible because the inventory is fragmented. Marketing owns campaign URLs. Product owns onboarding links. Support owns documentation. Nobody owns the namespace as a system.

A practical redirect-resilience checklist

You do not need to turn every redirect into a distributed-systems project. You do need enough discipline to know what matters and recover quickly.

1. Inventory critical links

Record the source URL, destination, owner, purpose, and replacement path for links used in:

Revenue-generating campaigns
Product onboarding
Documentation
Customer support
Printed material
Partner integrations
Mobile and desktop applications

A redirect without an owner becomes technical debt when the original campaign ends.

2. Monitor the whole path

An HTTP 200 from one location does not prove that the full path works for every user. Check DNS, the redirect response, and the destination separately:

dig +short go.example.com
curl -I https://go.example.com/docs
curl -I https://docs.example.com/getting-started

For high-value links, run checks from multiple locations and record the complete redirect chain. A chain can end in 200 while adding latency and extra failure points.

RedirHub's link health monitoring is designed for this operational layer: it checks critical links from global locations and alerts when a monitored destination fails. It does not replace registrar or registry controls, but it makes the failures within your routing layer visible before users report them.

3. Keep the configuration portable

Export redirect rules regularly. Preserve:

Source hosts and paths
Destination URLs
Status codes
Path and query-string behavior
Ownership metadata
Change history

A redirect platform should give you control of the routing data, not turn it into a black box. RedirHub supports CSV import and export, bulk changes with dry-run safety, and API access so teams can rebuild or audit their redirect layer without manual re-entry.

4. Separate namespaces when the impact justifies it

One domain is easier to remember. Separate domains can reduce blast radius. A company might separate product documentation, customer communications, paid campaigns, and internal tools.

This does not remove registrar, DNS, or provider risk. It limits how much fails together. Use separation where the business impact justifies the additional operational work; do not create domains merely to make the architecture look sophisticated.

5. Plan for change

The value of a redirect is that the destination can change without changing the published link. That only works when the redirect layer remains under active ownership.

Review high-value rules. Remove stale destinations. Test migration rules before launch. Keep a record of why each rule exists. A redirect is not finished when it is created—it remains part of the system for as long as someone depends on it.

What a managed redirect layer can—and cannot—do

The t.me incident was a registry-level event. No redirect dashboard can make a registry hold disappear. Resilience starts by separating the risks you can control from the risks you cannot.

A managed redirect layer can help with:

Centralized rule ownership
Bulk import and export
API-based updates
Redirect analytics
Health monitoring for critical links
Global edge delivery
Clear separation between source URLs and destinations

That is the problem RedirHub is built to solve. RedirHub is not a vanity-link generator. It is the routing layer between a URL people use and the destination that serves them. The dashboard gives marketing and operations teams control; the API gives engineering teams a path to automate changes.

The goal is straightforward: keep every link pointed in the right direction, and make failures visible before users find them.

The takeaway

The t.me outage lasted about a day, but the engineering lesson is durable:

Short links are convenient. Reliable routing is the system behind them.

Know who owns the domain. Monitor the complete path. Export the configuration. Understand the blast radius. Keep a recovery option for the links that matter most.

If a link is part of your product, your revenue funnel, your documentation, or your software, it deserves the same operational attention as any other production dependency.

Connect Any AI Agent to RedirHub in 5 Minutes - Claude, Cursor, or Codex

Redirhub — Fri, 10 Jul 2026 11:38:50 +0000

You manage redirects through a dashboard. Your AI agent just sits there, smart but disconnected.

There's a better pattern: give it MCP access and let it manage your redirects directly — from the same chat where you plan your deployment.

I'll show you the setup for Claude Desktop, Cursor, and VS Code / Codex. It takes about five minutes, and the Free plan is enough.

Step 1: Generate a Workspace API Token

Log into your RedirHub dashboard and go to Settings → API Tokens. Click Generate Token, name it something like "Claude Desktop" or "Cursor MCP", and copy the token — it starts with rh_ and is shown only once.

Keep this token private. You can revoke or rotate it anytime from the same page.

Even on the Free plan, you get full access to the MCP server — 17 tools and 15 resources. No upgrade needed.

Step 2: Add the MCP Config to Your Client

The server endpoint is:

https://api.redirhub.com/mcp/v1

Authentication is a Bearer token in the Authorization header. Each client handles config differently — pick yours.

Claude Desktop

Claude Desktop reads MCP servers from a JSON config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

Open or create this file and add:

{
  "mcpServers": {
    "redirhub": {
      "command": "npx",
      "args": [
        "-y",
        "@anthropic/mcp-client",
        "https://api.redirhub.com/mcp/v1",
        "--header",
        "Authorization: Bearer YOUR_API_TOKEN"
      ]
    }
  }
}

Replace YOUR_API_TOKEN with the token from Step 1. Save the file, then completely quit and reopen Claude Desktop (Cmd+Q on macOS — closing the window isn't enough).

After restart, look for a small 🔌 icon in the chat input bar. Click it — you should see 17 RedirHub tools listed.

Cursor

Cursor uses a .cursor/mcp.json file in your project root:

{
  "mcpServers": {
    "redirhub": {
      "url": "https://api.redirhub.com/mcp/v1",
      "headers": {
        "Authorization": "Bearer YOUR_API_TOKEN"
      }
    }
  }
}

Save the file and restart Cursor (or run Developer: Reload Window from the command palette). The RedirHub tools will now be available in Cursor's AI chat.

VS Code / Codex

OpenAI Codex reads from .codex/mcp.json — same format as Cursor:

{
  "mcpServers": {
    "redirhub": {
      "url": "https://api.redirhub.com/mcp/v1",
      "headers": {
        "Authorization": "Bearer YOUR_API_TOKEN"
      }
    }
  }
}

Save it in your project root and restart the Codex extension. You can also configure this globally via Codex's settings panel under MCP Servers → Add Server.

Any Other MCP Client

HTTP transport at https://api.redirhub.com/mcp/v1 with a Bearer token header. Consult your client's MCP docs if the format differs.

Step 3: Your First AI-Powered Redirect

Your client is connected. Let's do something real — skip the dashboard entirely.

Create a 301 Redirect via Chat

Open your AI client and type:

"Create a 301 redirect on RedirHub. The source URL should be /summer-sale on my domain, pointing to https://myshop.com/summer-2026. Use dry-run mode first so I can preview it."

Your agent will:

Call the CreateLink tool with dry_run: true
Show you exactly what will be created — the source, destination, redirect type, and which workspace it lives in
Wait for your confirmation before going live

Once you confirm, the redirect is created instantly. Same result as the dashboard form, but you never left your chat.

List All Your Links in One Message

Now try:

"List all my short links in my active RedirHub workspace."

Your agent calls the ListLinks resource and returns them formatted — domain, slug, destination URL, and status. No filtering dropdowns, no pagination clicking.

This is the mental-model shift: you're not filling out forms anymore. You're having a conversation with your infrastructure.

5 Real Prompts to Try

Here are prompts that go beyond the basics. Copy-paste any of them into your connected AI client:

1. Bulk import from a CSV

"I have a CSV at ~/redirects.csv with columns 'from' and 'to'. Import all of them into RedirHub as 301 redirects. Use dry-run first."

2. Find and fix broken links

"Check all my redirects that point to 404 destinations. List them and offer to update each one to a working URL."

3. UTM parameter sweep

"Add UTM parameters to all my links tagged 'spring-campaign'. Append ?utm_source=newsletter&utm_campaign=spring2026 to each destination URL."

4. Domain migration prep

"Export all redirects from my workspace as JSON. I'm migrating domains and need a full inventory first."

5. Analytics check

"Show me the top 10 most-clicked redirects this month with their click counts and last-clicked timestamps."

Troubleshooting

Symptom	Fix
🔌 Plug icon missing	Quit Claude completely (Cmd+Q), not just close the window
"Cannot connect to MCP server"	Verify the token is correct and not expired. Regenerate in Settings → API Tokens
Cursor not showing tools	Check `.cursor/mcp.json` is in your project root, not your home directory
Codex tools not appearing	Try the global config path via settings panel instead of `.codex/mcp.json`
Agent says "I don't have that tool"	Restart the client. Some IDEs cache MCP servers at startup only

That's it. You now have an AI agent that can read, create, update, and delete redirects on your behalf. The same setup works whether you're managing five redirects or five thousand — the only difference is the prompt you type.

Originally published on RedirHub Blog

Build a Redirect Bot: From Zero to AI-Powered Redirect Manager with MCP

Redirhub — Mon, 06 Jul 2026 08:18:51 +0000

Managing redirects for a growing site or portfolio is the kind of work that doesn't scale — create the record, verify DNS, check SSL, monitor uptime, update when something changes. Multiply that by hundreds or thousands of domains and it's a full-time job.

I built a redirect bot that handles all of this. It took 10 minutes, used zero custom code, and works with any AI agent that supports MCP (Model Context Protocol). Here's the exact playbook.

What a Redirect Bot Can Do

A redirect bot is an AI agent connected to a redirect management API through MCP. Once connected, it handles:

Create and manage redirects — add, update, or remove rules with a natural-language command
Bulk import from CSV — drop a spreadsheet into the conversation and the bot processes hundreds of records
Monitor link health — check redirect status, SSL validity, and DNS config across your portfolio
Alert on failures — push to Slack or email when a redirect breaks
Deployment workflows — move configs from staging to production with approval gates
Team collaboration — multiple people manage redirects through shared workspaces with role-based permissions

The key insight: this isn't a custom integration. It's built on MCP, an open protocol any AI agent understands. It works with Claude today, Codex tomorrow, and whatever ships next month — no rewrites.

Step 1: Connect to RedirHub MCP

The MCP server is available on every RedirHub plan, including free.

Get your API token:

Log into your RedirHub dashboard
Workspace → API Tokens
Generate a token with redirect management permissions

Configure your AI agent. For Claude Desktop, add this to claude_desktop_config.json:

{
  "mcpServers": {
    "redirhub": {
      "command": "npx",
      "args": ["-y", "@redirhub/mcp-server"],
      "env": {
        "REDIRHUB_API_TOKEN": "your-token-here"
      }
    }
  }
}

For Codex or Cursor, point the MCP config at https://api.redirhub.com/mcp/v1 with your Bearer token.

Verify it. Open your AI agent and ask: "List my redirects." If it returns your records, you're connected.

Step 2: Bulk Import from CSV

Manual redirect creation is the biggest time drain — especially during migrations. The bot handles this in one shot.

Workflow:

Export your redirect list as CSV (source URL, destination URL, redirect type)
Drop the CSV into your AI agent conversation
The bot processes all records via MCP's BulkImport tool and reports results

Example prompt:

"Here's a CSV with 150 redirects for our website migration. Create all of them as 301 redirects on RedirHub. For any that fail, tell me the source URL and the error reason."

The bot uses dry-run mode by default — you preview changes before committing. This matters for large migrations where a CSV typo could take down production pages.

Real result: A marketing agency migrated 850 redirects from an old CMS in 4 minutes. Manual creation would have taken two full days. The bot flagged 3 records with invalid destination URLs — fixed and re-imported in 30 seconds.

Step 3: Monitoring + Slack Alerts

A redirect that breaks silently is worse than no redirect. The bot watches:

Target URL status — is the destination still alive?
SSL certificate validity — is HTTPS working?
DNS configuration — is the domain still pointed correctly?
Response time — is the redirect fast enough?

Prompt:

"Monitor all my redirects and alert me in Slack if any destination returns a 4xx or 5xx. Check every hour."

The bot uses RedirHub's link health monitoring (Pro+) combined with GetAccessLogs and GetStats MCP tools. Slack alerts come through a webhook:

🚨 Redirect alert: old-site.com/blog → new-site.com/articles returned 404
Last successful check: 2 hours ago
Action needed: Update the destination or restore the target page

This flips redirect management from reactive ("someone reported a broken link") to proactive ("I know before anyone notices").

Step 4: Deployment Workflow (Staging → Production)

For teams managing redirects across environments, a deployment pipeline keeps things safe.

Workflow:

Create and test redirects in a staging workspace
The bot generates a diff of staging vs. production
A team member approves
The bot deploys changes to production in one batch

Prompt:

"Compare my staging and production workspaces and show me the diff. Then deploy all staging-only redirects to production."

The bot uses QueryResource to compare records across workspaces, then BulkUpdateRecords with the dry-run flag to sync changes safely.

Real result: A SaaS company managing 2,000+ redirects across 12 marketing sites used this workflow. Before the bot: one broken redirect per release. After: zero in six months.

Step 5: Team Collaboration + Approval Flows

Redirects shouldn't be managed by one person. With MCP, the bot coordinates across your team.

Approval flows:

"Any redirect targeting production domains needs DevOps approval. Marketing domains auto-approve and post a Slack notification."

The bot checks the destination domain of each request and routes through the appropriate channel. Marketing gets campaign redirects instantly. Production changes get a second pair of eyes.

Results: Before vs After

Metric	Before Bot	After Bot
Time to create 100 redirects	3–4 hours	2–3 minutes
Broken redirect detection	Days (user reports)	Minutes (automated)
Deployment errors per release	1–2	0
Team members managing redirects	1–2 (bottleneck)	Anyone (self-serve)
DNS/SSL issues found weekly	Manual spot-checks	Automated daily scan

The common thread: redirect management stops being a specialized task. Your SEO specialist doesn't need to learn an API. Your marketing manager doesn't need dashboard access. They just ask the bot.

What's Next

A redirect bot on MCP isn't a future project — it's something you can set up today on the free plan. Connect your AI agent, run your first bulk import, set up monitoring. The tools are open source, the protocol is standard, and the setup takes two minutes.

The only question is what you'll do with the hours you get back.