Affiliate Tracking Not Working on WordPress? The 9 Causes, in Testing Order
A referral happened and no commission appeared. Work through the nine real causes in the order that finds them fastest — caching, cookie blockers, redirect chains, consent plugins, self-referral rules — with a test for each.
An affiliate swears they sent a buyer. The order exists. The commission does not. Before anyone starts doubting anyone's honesty, know this: almost every "tracking is broken" case traces to one of nine causes, and you can identify yours in under an hour by testing in the right order.
Test with a clean setup each time: a private/incognito window, not logged into your own site, using the affiliate's actual link exactly as they share it.
| Symptom | Start with cause |
|---|---|
| No visits recorded at all | 1, 4, 5 |
| Visits recorded, no cookie | 2, 5, 6 |
| Cookie set, order not credited | 3, 7, 8, 9 |
| Only some affiliates affected | 4 (their links), 8 |
1. Page caching serves cookie-less HTML
The most common cause on WordPress, full stop. If tracking runs in PHP and your cache plugin (or host-level cache) serves a stored copy of the landing page, the tracking code may never execute for cached visitors.
Test: open the affiliate link in a private window and check whether the referral cookie exists (browser dev tools → Application → Cookies). Then check your visits screen. Fix: a well-built plugin sets the cookie before the cache responds or excludes referral-parameter URLs from cache; make sure URLs containing your referral parameter (?ref=) are excluded in the cache plugin's settings. Almost every cache plugin has this exclusion field.
2. Ad blockers and privacy browsers eat script-based tracking
If your affiliate solution tracks with a JavaScript snippet calling a third-party domain, ad blockers and browsers like Brave block the call and the visit never happened, as far as tracking is concerned — silently, for 20–40% of a typical audience. Test: visit the link with an ad-blocker on and off; compare. Fix: this one is architectural. First-party, server-side tracking has no third-party script to block — it is the reason self-hosted tracking survives the modern web better than script-tag platforms.
3. Safari's seven-day JavaScript cookie cap
Safari (and iOS in-app browsers) cap cookies written by JavaScript at seven days. A "30-day cookie window" quietly becomes seven for a large slice of mobile traffic when the cookie is set client-side. Test: ask where your plugin sets its cookie — server (HTTP header) or JavaScript. Fix: server-set cookies with your own domain keep their full duration; coupon-code attribution covers even the visitors who clear cookies entirely.
4. A redirect strips the referral parameter
http://site.com/?ref=jane → redirects to https://www.site.com/ — and if any hop in that chain drops query strings, the parameter dies before your plugin sees it. Affiliates cause this too, by sharing links through shorteners or old http URLs. Test: paste the affiliate's exact shared link and watch the address bar after landing — is ?ref= still there? Fix: make sure www/https redirects preserve query strings (default WordPress redirects do; some CDN or security rules don't), and hand affiliates clean vanity links so nobody builds their own.
5. A consent plugin blocks tracking until "Accept"
EU-focused consent plugins can block cookie-setting scripts until the visitor consents — and most visitors never click anything. Whether affiliate tracking belongs behind that wall is a configuration decision with legal nuance; many stores treat first-party referral attribution as legitimate-interest functional tracking. Test: visit the link, ignore the consent banner, check for the cookie. Fix: in your consent tool, classify the referral cookie appropriately (functional vs marketing) after reading the linked piece — deliberately, not accidentally.
6. Cookie domain mismatch
Cookie set on www.store.com, checkout served on store.com (or a subdomain), cookie invisible at checkout. Rare on tidy setups, common after domain migrations. Test: compare the domain in the address bar on landing vs at checkout; look at the cookie's Domain attribute. Fix: consistent canonical domain, and a cookie scoped to .store.com.
7. Checkout happens somewhere else
Off-site payment pages (hosted checkout services, external booking tools, "buy" buttons that leave your domain) complete the sale where your cookie does not exist. Test: walk the full purchase path — does the order get created on your WordPress site? Fix: keep order creation on-site (WooCommerce's native checkout, including the block checkout, is fine — the payment redirect afterward doesn't matter because attribution stamps when the order is created), or use coupon codes as the attribution bridge.
8. The self-referral and exclusion rules are doing their job
The affiliate tested their own link, logged into their own account, or bought through it themselves — and the plugin's fraud rules correctly declined the credit. Also common: the affiliate's own purchase excluded by a "no self-referrals" setting they didn't know about. Test: reproduce as a genuinely different customer (different browser profile, not their account). Fix: nothing — except telling affiliates how to test properly: incognito window, dummy order, marked as test.
9. The commission triggers on a status the order never reached
Plugins credit commissions at a configured order status — often completed. Stores selling physical goods sometimes leave orders at processing for days, and dashboards look broken while everything is actually queued. Refunded or failed orders reverse correctly rather than pay. Test: check the order's status against the plugin's trigger setting. Fix: align the trigger with your fulfillment reality; for digital goods, credit on processing/completed both.
When you've fixed it, tell the affiliate what happened
The silent damage of tracking bugs is trust: an affiliate who believes clicks vanish stops sending them. When you find the cause, say so plainly — "our cache was eating referral visits for three days, here's what we credited manually." A transparent, explainable ledger is what keeps partners through incidents; manually credit anything the bug cost them, and the incident becomes a loyalty story instead of a churn story.
Quick answers
Why is my affiliate link not setting a cookie on WordPress? In testing order: page caching served HTML without executing the tracker, an ad blocker blocked a third-party script, a redirect stripped the ?ref= parameter, or a consent plugin held the cookie back. Test in a private window with dev tools open — the cookie panel tells you in seconds.
Why did an affiliate get no commission although the customer ordered? Usually one of: the cookie expired or never survived Safari's JS cap, checkout completed off-site, the order sits in a status that doesn't trigger commissions yet, or a self-referral/exclusion rule declined it on purpose. The referral log plus the order's status history answers it.
How do I test affiliate tracking properly? Private window, logged out, the affiliate's exact link, a real test order (small amount or a 100% test coupon), then check: visit recorded → cookie present → referral created → commission at the right status. Whichever step fails first names your cause.