Managing Affiliate Links: Redirects, a Registry and Link Rot
Keep hundreds of tracking links working: one redirect path, a registry with an expected destination per row, a weekly test of every link, and rot maths.

A site with forty pages and three programs can easily carry 120 tracking links in its HTML. Nobody notices when one of them breaks. The reader clicks, lands on an error page or on the wrong brand's homepage, and leaves. Nothing reports the failure: the program's dashboard simply shows fewer clicks and no depositors from that page, which reads like a slow month. Managing affiliate links is an operations job that almost nobody budgets for, and the cost of skipping it grows with every page you publish. This guide sets out the three pieces that keep links working: one redirect path, a registry, and a scheduled test.
Why links stop working
Most of the reasons a tracking link fails are outside your control:
- The program moves to a different affiliate platform and issues new tracking links; the old domain stops resolving months later.
- A brand closes, is sold, or withdraws from the market your readers are in.
- A campaign or promotion page a deep link pointed at expires.
- The operator changes how it routes visitors by country, and a link that used to land on the right local site now lands on a "not available in your region" page.
- Your account is changed or re-issued, and the old tracking code stops crediting you.
- An edit breaks a parameter: a missing ampersand, a subID with a space in it, a link copied with the wrong campaign code.
Only the last of those is a mistake on your side, and all of them look identical from the reader's chair.
Put one redirect path between your pages and the programs
The single most useful structural decision is to stop pasting program URLs into pages. Instead, every affiliate link on the site points to a short path on your own domain, such as /go/brand-name, and that path redirects to the current tracking link. The page never contains the program's URL at all.
This gives you four things a pasted link cannot:
- One place to change a link. When a program re-issues a tracker, you update one row and every page that links to that brand is fixed in the same minute.
- Your own click log. The redirect can record a timestamp, the page the click came from and the subID before it sends the visitor on. That log is the independent record you need when a program's numbers look wrong.
- Consistent subIDs. The redirect can append the page or placement as a subID automatically, so you never type one by hand.
- A place to test. Every link the site uses is listed in one table that a script can walk.
What the redirect itself should do
- Answer with a temporary redirect (302 or 307), so the target can change without anything caching an old destination.
- Pass the program's parameters through untouched, and add your own subID without overwriting theirs.
- Send a noindex header, and disallow the redirect path in robots.txt, so crawlers do not spend requests on it or list it.
- Fail cleanly: an unknown id should return a plain 404, not a redirect to the homepage, so a typo shows up in your logs instead of disappearing.
On the page itself, the link still has to be marked for what it is. Google asks publishers to qualify paid and affiliate links with rel="sponsored"; the glossary entry on the sponsored attribute explains it. A redirect path is not a disguise. The reader can see where the link goes once they click, and the commercial relationship is disclosed on the page, not hidden in the URL.
Keep a registry: one row per tracker
The redirect needs a table to read from, and that table is also your inventory. One row per tracking link, with at least these columns:
| Column | What it holds |
|---|---|
| id | The short name the redirect path uses |
| Program and brand | Who pays for clicks through this link |
| Market | The country or language the link is meant for |
| Tracking URL | The exact link as the program issued it |
| Expected destination | The domain a visitor in that market should end up on |
| Added | The date the link was issued or last replaced |
| Last test | The date and result of the most recent test |
The expected destination column is the one most registries leave out, and it is what turns a test from "did the link answer" into "did the link take a reader where it should". A link that answers with a 200 on the wrong brand's homepage is still broken.
Test every link on a schedule
A weekly script that walks the registry, follows each link's redirects to the end, and compares the result with the expected destination catches most of the failures in the list above within seven days. A re-issued account is the exception: the old link still lands correctly and simply stops crediting you, which only the statement shows. The things to flag:
- Any error status at the end of the chain (4xx or 5xx), or a chain that never ends.
- A final domain that does not match the expected destination.
- A final page whose content says the brand is unavailable in the visitor's country.
- A chain that drops your tracking parameters before it reaches the operator, where the chain is visible.
Test from the market you publish for
Operators route visitors by country, so the same tracking link can land on a local licensed site for one reader and a refusal page for another. A test that runs on a server in a different country can pass while every real reader fails, or the reverse. Run the weekly test through a network location in each market you publish for, and record the market alongside each result in the registry.
Deep links need more frequent testing
A deep link points to a specific page on the operator's site, such as a promotion or a game, instead of its homepage. It converts better because it removes a step, and it breaks more often because promotion pages expire. Test deep links more often than homepage links, or set every deep link to fall back to the brand's default link when the target page disappears.
The arithmetic of link rot
Illustrative numbers, to show the scale. Take 120 tracking links, each with a 1.5% chance of breaking in any given month for one of the reasons above. After twelve months the expected number still working is 120 × 0.985^12 = 120 × 0.834 = 100. About twenty links break in a year, more than one a month.
The cost depends on which links break. Clicks are rarely spread evenly: a few pages usually carry most of them. Suppose the busiest link on the site produces six first-time depositors a month. If it breaks and nobody notices for six weeks, it loses 6 × 1.5 = 9 depositors. At an illustrative value of EUR 100 per depositor, that is EUR 900. With a weekly test, the longest it can stay broken is about a week, which caps the loss at 6 × 12 ÷ 52 = 1.4 depositors, roughly EUR 140. The weekly test pays for itself the first time it catches a link on a page that matters.
There is a second cost that does not show in the arithmetic. A month of zero depositors from a page that used to convert looks like a content problem, and the natural response is to rewrite the page. Rewriting a page because its link broke is effort spent on the wrong cause. The diagnostic order that rules out broken links first is in anatomy of a dead funnel.
A setup checklist
- Every affiliate link on the site points to a redirect path on your own domain.
- The redirect reads from a registry with one row per tracker and an expected destination for each.
- Each redirect logs the click with a timestamp, the source page and a subID.
- The redirect path is noindex and disallowed in robots.txt; links on the page carry
rel="sponsored". - A weekly test follows every link to its end, through each market you publish for.
- Failures arrive somewhere you actually read, not in a log nobody opens.
- When a program announces a platform move, every one of its rows is retested the same day.
Common questions
Is a redirect path the same as cloaking?
No, not in the sense search engines object to. Cloaking means showing crawlers different content from what readers see. A redirect path shows everyone the same page and the same link, marked as sponsored, and sends everyone to the same destination. It is a management layer, and the disclosure obligations stay exactly where they were.
How should subIDs be structured?
One token for the site, one for the page, and one for the placement on the page, joined the same way every time. The tracking and postbacks guide covers subIDs in detail. The redirect path is what makes the scheme consistent, because it is applied in code rather than by hand.
What about links inside emails or social posts?
Point them at the same redirect path, with a subID that names the channel. A link that leaves the site in an email is the hardest one to fix after it breaks, because the email is already in someone's inbox. Routing it through your own domain is the only way to repair it after sending.
What we would do this week
- Count the tracking links on the site that point straight at a program URL. If there are more than a handful, plan the move to a redirect path before adding another page.
- Build the registry, even as a spreadsheet, with the expected destination filled in for every row.
- Follow each of your ten busiest links by hand today, through the market each one is meant for, and note anything that does not end where it should.
- Schedule a weekly automated test of the full registry, and decide where its failures will be sent.
Next in this trackReview Site, Comparison Site or Blog: Which Model Fits You?