This is the lean affiliate redirect system I run on devonkorr.com. No WordPress plugins, no paid affiliate-tracking subscription, no database. One file, a handful of /go/ routes, and Cloudflare Pages doing the work in the background. The article walks through the setup, the naming convention, the gotchas, and the maintenance pattern. If you're building a content site that recommends external tools, this is the infrastructure that keeps your CTAs clean and your affiliate URLs maintainable.

The Problem This Solves

I Did Not Want Affiliate Links Scattered Across the Site

When I started building Devon Korr, I had a choice to make about affiliate links. The lazy path was to paste raw affiliate URLs directly into every article CTA. The expensive path was to bolt on a WordPress plugin or a paid affiliate-tracking service. Both options would have worked, and both have real costs.

I picked the lean operator path: keep one canonical /go/ URL per tool, point it at the affiliate destination once, and let Cloudflare Pages handle the redirect. Every article on the site links to routes like /go/hostinger, /go/systemeio, /go/make, /go/kit, or /go/elevenlabs. The ugly affiliate tracking URLs live in one file. When a program changes its tracking parameters or I switch affiliate networks, I update one file and redeploy. The article CTAs stay clean.

The benefits are operational, not financial. Fewer broken links. Easier updates when affiliate programs change. Cleaner CTAs in article body copy. A controllable audit trail when something looks wrong. No plugin database to maintain. No subscription to renew. The system has held up across the BOFU comparison articles in the Hub 3 cluster and the recommendations on the pillar.

Why I Avoided Plugins and Paid Tracking Tools

DevonKorr.com runs on Astro and Cloudflare Pages. Not WordPress. That means WordPress redirect plugins are out of scope from day one. ThirstyAffiliates, Pretty Links, Lasso, AffiliateWP — all the heavyweight WordPress-only options — none of them apply to my stack.

Paid affiliate-tracking services exist (LeadDyno, Tapfiliate, Refersion, others) and they have real use cases for businesses with their own affiliate programs to manage. For a solo operator pointing visitors at other companies' affiliate programs, paying $20 to $50 per month for tracking infrastructure is overkill before traffic exists. The basic requirement is centralizing outbound affiliate redirects. Cloudflare Pages already handles that.

This is the same approach I take across the rest of the Devon Korr stack: buy tools when they remove proven constraints, not because every affiliate site is supposed to use a particular SaaS layer. The full reasoning is in the pillar article on the AI tool stack for beginners.

Disclosure Runs Alongside Redirects

Clean /go/ URLs are infrastructure. They don't replace affiliate disclosure. The redirect system controls outbound routing. It does not disclose affiliate relationships to readers.

Devon Korr's affiliate disclosure lives at /affiliate-disclosure/, linked from every page. Every article that uses /go/ links also carries an inline disclosure near the recommendations. The redirect infrastructure and the disclosure obligations are two separate jobs. Set them up together, but don't confuse one for the other. For the full compliance architecture — placement rules, plain-language templates, and audit checklists — see FTC Affiliate Disclosure for Solo Operators: The 2026 Compliance Architecture.

The Live Redirect Set I Use Now

The current public /go/ routes on devonkorr.com map to the affiliate programs I've been approved for: ElevenLabs, Hostinger, Kit, MailerLite, Make, Notion, Skool, and Systeme.io. Additional routes get added by editing the same _redirects file and redeploying. No plugin activation. No dashboard configuration. One file, one git commit.

The Architecture Overview

The Moving Parts

The stack is intentionally narrow. DevonKorr.com is built on Astro and deployed to Cloudflare Pages. The redirect rules live in a single file at public/_redirects. During every build, Astro copies the public/ directory into the deployed output. Cloudflare Pages reads the _redirects file from the deployed root and applies the rules to incoming requests. Internal /go/ links in article bodies hit those rules and route to external affiliate destinations.

There's no plugin layer. No middleware. No database. The system has four moving parts: the Astro project, the public/_redirects file, the Cloudflare Pages deployment, and the /go/ URLs used inside articles.

What the Redirect File Does

The _redirects format is one rule per line. Each rule has three fields:

[source] [destination] [code?]

The source is the internal path (like /go/hostinger). The destination is the external URL the redirect should send the visitor to. The status code is optional. When omitted, Cloudflare Pages defaults to a 302 redirect, which is the right default for affiliate links that may change.

That's the entire syntax for the basic use case. One line per affiliate program. Run the file from the static asset directory, redeploy, and Cloudflare handles the rest.

What This Setup Does Not Do

Worth stating explicitly. The /go/ redirect system handles outbound routing. It does not:

  • Replace affiliate-network reporting (the official click and conversion data still lives in each program's affiliate dashboard).
  • Track conversions on its own (only the affiliate networks see the eventual signup or purchase).
  • Remove the need for affiliate disclosure (the redirect routes are infrastructure, not legal cover).
  • Catch redirect failures automatically (you still need to test every new /go/ route after deployment).

Knowing the boundary protects against assuming the redirect system is doing more than it actually is.

One file, one git commit. The article CTAs stay clean.

Step-by-Step Setup

Step 1 — Create public/_redirects

In the Astro project root, create a file at public/_redirects. No extension. The exact filename matters; Cloudflare Pages looks for _redirects literally.

For Astro projects, public/ is the right directory because everything in public/ gets copied verbatim into the build output. Astro doesn't process or transform the _redirects file. It just makes sure it ends up at the deployed root where Cloudflare Pages expects to find it.

If your stack is different (Next.js, SvelteKit, vanilla static site), Cloudflare's current documentation lists the equivalent static-asset directory for each framework. Re-check the docs if you're not on Astro.

Step 2 — Add One Redirect per Affiliate Destination

Each line in _redirects is one rule. The general pattern:

/go/tool-name https://affiliate-network.example.com/tracking-link 302

The internal source path, the external destination URL, the status code. Spaces between fields.

For Devon Korr's live set, the file looks something like this (placeholder destinations — your real affiliate URLs go here):

/go/elevenlabs https://example.com/elevenlabs-affiliate-link 302
/go/hostinger https://example.com/hostinger-affiliate-link 302
/go/kit https://example.com/kit-affiliate-link 302
/go/mailerlite https://example.com/mailerlite-affiliate-link 302
/go/make https://example.com/make-affiliate-link 302
/go/notion https://example.com/notion-affiliate-link 302
/go/skool https://example.com/skool-affiliate-link 302
/go/systemeio https://example.com/systemeio-affiliate-link 302

I've used placeholder URLs in this example because each affiliate program assigns you your own tracking parameters. Substitute your actual affiliate URLs here. Don't copy mine; they include my referral codes, and using them would credit signups to me instead of you.

Keep each line readable. When you come back six months later to update an affiliate URL because the program changed networks, the file should be auditable at a glance.

Step 3 — Use /go/ Links Inside Articles and CTAs

Inside article body copy and CTA components, link to /go/tool-name, not to the external affiliate URL directly. That's the entire point of the system. If you're writing a comparison article that recommends Hostinger, the link target is /go/hostinger, not the raw affiliate URL.

This pattern keeps destination changes centralized. When Hostinger updates its affiliate program (or you switch to a different affiliate network for the same tool), you update one line in _redirects and redeploy. Every article that used /go/hostinger immediately picks up the new destination. No bulk find-and-replace across multiple articles. No risk of missing a CTA in an older post.

The Hub 3 BOFU comparisons rely on this:

All three articles use /go/ redirects for their CTAs.

Step 4 — Commit, Deploy, and Verify

The deployment flow is standard git plus Cloudflare Pages auto-deploy:

  1. Edit public/_redirects.
  2. Commit the change.
  3. Push to the main branch (or whichever branch Cloudflare Pages is configured to deploy from).
  4. Cloudflare Pages builds the project and deploys the updated _redirects.

After deploy, visit each /go/ URL in a browser and confirm it lands on the intended external page. Use browser dev tools, curl -I, or an online redirect checker to confirm the status code matches what you set. Don't trust that "it should work" just because the file shipped.

Step 5 — Choose the Status Code Intentionally

The status code field defaults to 302 when omitted. For affiliate links, that default is usually correct.

Use 302 (temporary) when the affiliate destination might change. That covers most affiliate links, because programs swap networks, update tracking parameters, or sunset products. Browsers and search engines treat 302s as non-cached redirects, which means a change to the destination takes effect immediately.

Use 301 (permanent) only when the destination is genuinely permanent. Browsers and search engines cache 301s aggressively. If you set /go/hostinger to 301 and Hostinger later changes its tracking URL, some visitors will keep getting routed to the old destination from cache for days or weeks.

For affiliate routes specifically, 302 is the safer default. Stay there unless you have a specific reason to commit to permanent.

The /go/ URL Naming Convention

Keep Names Short, Boring, and Stable

The convention I use: /go/brand or /go/tool. Lowercase. No spaces. No dates. No category prefixes.

Current Devon Korr routes:

  • /go/hostinger
  • /go/systemeio
  • /go/make
  • /go/kit
  • /go/mailerlite

Each one is short enough to read aloud, easy to remember when writing CTAs, and stable across articles. The convention works because it's boring. Boring is what you want from infrastructure.

Do Not Expose Tracking Mess in Public CTAs

The whole point of the redirect file is to keep ugly affiliate URLs out of article body copy. A CTA that says "Sign up at https://www.hostinger.com/?REFERRALCODE=...&utm_source=..." looks untrustworthy. A CTA that says "Sign up via /go/hostinger" looks clean.

Public-facing components should always link to the /go/ path. The full tracking URL lives in _redirects and nowhere else. This also reduces the chance of pasting the wrong tracking URL into an older article and forgetting about it.

Add Variants Only When There Is a Real Reason

Variants make sense when you need different destinations for the same tool under different contexts. Something like:

  • /go/hostinger-wordpress for a Hostinger CTA on a WordPress comparison page.
  • /go/make-automation for a Make CTA when the article angle is automation specifically.

These work because the affiliate program supports campaign-level tracking and you want attribution by article context.

What doesn't work: creating variants because they "might be useful one day." Every variant is one more line to maintain. Start with one canonical /go/ link per tool. Add variants only when you have a specific tracking or destination reason. Don't pre-populate the file with hypothetical routes.

Boring is what you want from infrastructure.

Redirects Are Not Analytics

What the Basic Setup Tracks, and What It Does Not

The _redirects file does one thing: route a visitor from an internal /go/ path to an external affiliate destination. By itself, it does not track clicks. Cloudflare Pages logs basic request traffic, but the redirect rule doesn't fire an analytics event, doesn't write to a database, and doesn't ping a tracking pixel.

For Devon Korr right now, this setup handles redirects. Click analytics is a separate layer that isn't covered in this article.

The affiliate-network dashboards remain the official source for clicks and conversion data. When Hostinger's affiliate dashboard shows a referral from devonkorr.com, that's the authoritative count. The redirect system isn't trying to duplicate that data.

What I Would Add Later If Needed

When the site grows to the point where internal click visibility matters (which is a real point, not an aspirational one), the next layer would be front-end click events for /go/ links. Track basic fields: destination slug, page path, CTA placement, timestamp. Nothing more.

If reporting volume gets to the point of needing automation around it, that's where Make enters the picture — not before.

Edge Cases and Gotchas

Redirect Loops and Wrong Destinations

A /go/ route can fail silently in two ways. The first is pointing to the wrong external URL. The second is creating a loop — where /go/X redirects to a URL that redirects back to the site, or to another /go/ route that loops.

Test every new route after deployment. Visit the URL in a browser. Confirm it lands on the intended external page. Use curl -I to confirm the status code, or a public redirect checker. Don't trust that the deployment worked just because the build succeeded.

Pages Functions Can Change the Behavior

Cloudflare's current documentation states that _redirects rules are not applied to requests served by Pages Functions, even when the route would otherwise match. If your project later adds a Cloudflare Pages Function under the /go/ path, the redirect handling for that route may need to move into the Function code instead.

This is a future-state warning, not a current problem for a static Astro site without Functions. If your stack stays static, you don't hit this. If you add Functions later, audit the /go/ routes against the new Function paths before assuming the redirects still apply.

Maintenance and Updates

Keep the Redirect File Boring

The _redirects file works because it's small and predictable. As the affiliate program list grows, organize entries alphabetically or by category. Add short inline comments only when they clarify something non-obvious. Don't turn the file into a graveyard of commented-out experimental routes from six months ago.

The discipline here is operational, not technical. Cloudflare Pages will happily parse a messy _redirects file. The maintenance cost is on the operator who has to figure out which rules are live, which were retired, and which should be removed.

Update One Destination, Not Twenty Articles

The main operational win of this system is in the maintenance pattern. When an affiliate destination changes, the update is a single line in _redirects followed by a redeploy. Every article that linked to that /go/ route immediately picks up the new destination.

For the Hub 3 BOFU comparisons specifically, this matters. The same tool CTA shows up in multiple sections across the Systeme.io vs WordPress, Make vs Zapier, and Claude vs ChatGPT articles. If each article hardcoded the affiliate URL, an update would require bulk find-and-replace across the cluster. With /go/ redirects, the update happens once.

Review Redirects as Part of Content Maintenance

When updating any article in the cluster, add a quick /go/ link check to the review. Click the redirect, confirm it lands on the right page, confirm the affiliate parameters still attribute correctly. This isn't a scheduled cadence, just a habit. When you're already in the article making changes, the cost of testing the outbound link is roughly zero.

What to Do Next

The /go/ redirect infrastructure is only useful if it sits underneath actual recommendations. The places where buying decisions happen on Devon Korr are:

Read the affiliate disclosure for the FTC-defensible boilerplate. Then build your version of this system. The first /go/ route you ship is the one that proves the pattern works.