An affiliate cookie is not set when a click on a monetized link reaches the merchant without leaving the identifier that ties a later purchase to the publisher. The most common causes are a missing or malformed tracking ID, a redirect that strips the parameter, a browser or consent setting that blocks storage, and a link that still loads but no longer points to a live offer. Each cause can be tested separately, and each test produces evidence that can be classified as Broken, Needs Attention or Healthy.
This article sets out the mechanism, the five failure categories, a test sequence a publisher can run on a single link, and the limits of what any outside check can establish.
TL;DR
- A cookie is set by the merchant's or network's server in response to a click, so a publisher cannot confirm it from the page that holds the link. The visible evidence is in the URL, the redirect chain and the response headers.
- Five causes account for most cases: missing tracking ID, redirect stripping, blocked or restricted storage, a merchant-side change (discontinued product or program), and consent or privacy tooling.
- A link that returns 200 OK can still fail commercially. Status codes alone do not show whether tracking is intact.
- Findings are best sorted into three labels: Broken, Needs Attention and Healthy, so that clear fixes are separated from items requiring manual review.
- No external check verifies that a commission was credited. Only the merchant's or network's reporting can confirm that.
Table of Contents
- What "cookie not set" means in practice
- Five failure categories
- Summary table
- A test sequence for a single link
- Classifying results: Broken, Needs Attention, Healthy
- Our perspective
- Where a structured audit fits
- Prioritizing what to review first
- Common mistakes when diagnosing a missing cookie
- FAQ
- Sources
What "cookie not set" means in practice
In most affiliate programs, a click sends the visitor to a merchant or network URL carrying an identifier (for example a tracking ID). The merchant's server responds, and the response may include a Set-Cookie header, which per the MDN documentation is the mechanism a server uses to send a cookie to the user agent so that it can be returned on later requests. The same documentation notes that browsers block frontend JavaScript from reading that header, which is why a publisher's own page scripts cannot observe whether the cookie was accepted.
That constraint defines the diagnostic problem. The publisher controls the link, the anchor and the page. The merchant controls the cookie. Between the two sit redirects, browser privacy rules and consent tools. A cookie that is "not set" is therefore a symptom with several possible origins, and the origin determines whether the remedy sits with the publisher or with the program.
Why the window matters
Cookie duration shapes how much a failure costs. Amazon's program, for instance, credits qualifying items added to a cart within 24 hours of a visitor arriving through an Associates link, and that window closes when the order is submitted or when the visitor re-enters through another Associate's link. Other programs publish different durations and rules. A short window means that a click which fails to set the identifier leaves little room for recovery on a later visit.
Five failure categories
1. Missing or malformed tracking ID
The link reaches the merchant without the parameter that identifies the publisher, or with a parameter that is truncated, misspelled or tied to a retired account. Amazon's own help page on checking whether links tag to your account states that the Store ID or Tracking ID most often appears in the URL as a tag parameter once the link is clicked. If the parameter is absent after the click, the identifier was lost before or at the merchant.
Typical origins on older content: links pasted from a product page instead of generated through the program's tools, plugin or theme changes that rewrite URLs, and tracking IDs from closed accounts. The client's guides on missing affiliate IDs and invalid Amazon Associate IDs cover these cases in detail.
2. Redirect stripping
A link may pass through a shortener, a cloaking plugin, a network redirect or a merchant's regional redirect. Any hop can drop query parameters, particularly when the destination changes (for example, a product page that now redirects to a category page or the homepage). The final URL loads and returns 200 OK, but the identifier that would trigger the cookie was removed along the way.
This is the category in which status-code checkers report "no problem" while the link is commercially unhealthy. The destination exists; the tracking path does not survive to it.
3. Blocked or restricted storage
Browsers differ in how they treat cookies. Google's documentation defines a third-party cookie as one set by a site different from the one the visitor is on, and its Privacy Sandbox overview describes the move to phase out third-party cookies and limit covert tracking. Affiliate redirects often behave as third-party interactions, so restrictions on cross-site storage can reduce how reliably the identifier persists. Ad blockers and strict browser modes add further variance.
This category is largely outside publisher control and rarely attributable to a single link. It is better understood as a background rate that affects every program, which is why link-level testing should isolate the causes that are within reach before attributing losses to the browser. For a broader view of how privacy changes alter attribution, the discussion of privacy-first retargeting strategies addresses the same shift from the marketing side.
4. Merchant-side change
The offer may have changed after the content was published: the product is discontinued, the program is closed, the landing page was replaced, or the tracking domain was retired. The link works at the transport level and fails commercially. The client's material on affiliate links that stop earning and on replacing dead affiliate programs treats this as the least visible and most common category on aging posts.
5. Consent and disclosure tooling
Consent banners and script managers can prevent scripts or pixels from firing when a visitor declines. Programs also place obligations on the publisher: the Amazon Associates program policies require accurate disclosure of the use of cookies, pixels and other technologies on the site, in accordance with applicable laws. Separately, the FTC's endorsement guidance addresses the disclosure of material connections, including commissions earned when readers click links. Disclosure and consent configuration should therefore be reviewed alongside tracking, not after it.
Summary table
| Category | Where the failure occurs | Typical evidence | Within publisher control |
|---|---|---|---|
| Missing or malformed tracking ID | Link source | Parameter absent or wrong in final URL | Yes |
| Redirect stripping | Redirect chain | Parameter present at hop 1, absent at final URL | Partly |
| Blocked or restricted storage | Visitor's browser | Varies by browser, mode and extension | Rarely |
| Merchant-side change | Program or product | Redirect to homepage, unavailable product, retired tracking domain | Replacement only |
| Consent and disclosure tooling | Site configuration | Scripts suppressed until consent; disclosure gaps | Yes |
A test sequence for a single link
The following sequence isolates each category using only a browser and its developer tools. It establishes evidence about the link and its path. It does not establish that a commission was credited.
- Record the source. Copy the link exactly as it appears in the page's HTML, not as rendered. Note whether it is a direct merchant URL, a network link, a shortener or a plugin-generated redirect.
- Confirm the identifier. Check that the tracking parameter is present and matches an active account or tracking ID. For Amazon links, Associates Central describes how to inspect the
tagvalue after a click. - Trace the redirect chain. In the browser's network panel, load the link with the cache disabled and list every hop. Note the status code at each step and whether the identifier survives.
- Inspect the final destination. Verify that the product, page or offer matches the anchor's promise. A redirect to a generic homepage, a category page or an unavailable-product page is a commercial failure even when the status is 200.
- Observe the response headers. On the merchant or network response, look for
Set-Cookie. Its absence at the hop that should set it is evidence; its presence is not proof of credit. - Repeat under different conditions. Test in a clean profile, with a content blocker enabled, and with consent declined. Differences isolate category 3 and category 5 from the link itself.
- Check program status. Confirm in the merchant or network dashboard that the program, product and tracking domain are active, and review the program's current terms. The client's guide to auditing affiliate program terms lays out a link-test routine for this step.
A publisher with a handful of links can run this sequence by hand. A site with hundreds or thousands of monetized anchors across years of posts cannot do so economically, and the choice then becomes between sampling and a structured audit.
Classifying results: Broken, Needs Attention, Healthy
A test sequence produces many observations. A classification scheme converts them into a work order. The client uses three labels.
- Broken: the evidence is unambiguous. Examples: a 404, a retired tracking domain, a tracking ID absent from the final URL where it should be present, or a destination confirmed as discontinued.
- Needs Attention: the link loads but the evidence is ambiguous or commercially weak. Examples: a redirect to a generic homepage, a parameter that survives only intermittently, an offer whose availability cannot be confirmed, or a tracking path that may no longer earn commission. These items require manual review by the publisher.
- Healthy: the link resolves, the identifier survives the redirect chain, and the destination matches the anchor's intent at the time of the test.
The distinction between Broken and Needs Attention matters operationally. Items in the first group can be queued for replacement without further investigation. Items in the second group should not be changed on assumption, because the cause may sit with the merchant, the network or the visitor's browser. The publisher decides what to change in either case.
A worked example of the labels
Consider a three-year-old review post with 12 monetized anchors. A status-code checker returns 200 OK for all 12. A path-level review might yield a different picture:
| Anchor | Observation | Label |
|---|---|---|
| 1 to 7 | Identifier present through all hops; destination matches product | Healthy |
| 8 to 9 | Final URL is the merchant homepage; identifier absent | Broken or Needs Attention, depending on whether the product is confirmed discontinued |
| 10 | Product page loads; availability message indicates unavailable | Needs Attention |
| 11 | Shortener returns a 404 | Broken |
| 12 | Identifier present, but program terms recently changed | Needs Attention |
This is an illustrative structure, not a measured result. Its point is that the same page produces three kinds of action: replace, review and leave alone.
Our perspective
We treat "affiliate cookie not set" as a symptom that cannot be diagnosed from one vantage point. A publisher sees the link; the merchant sees the cookie; the browser decides whether it persists. Our audits therefore concentrate on what an outside review can establish with evidence: whether the identifier is present, whether it survives the redirect chain, whether the destination is still a live offer, and whether the tracking path appears intact.
We do not verify that commissions were credited, and we do not estimate lost income. Neither can be established without access to the merchant's or network's own reporting, and any figure presented without it would be conjecture. We also do not repair links. We identify them, classify them as Broken, Needs Attention or Healthy, and supply the evidence and suggested replacements so that the publisher can decide.
The pattern we see most often in older content is not a missing cookie in the strict sense. It is a link that still loads and still looks acceptable, but whose commercial path has degraded. Because a standard link checker stops at the status code, that degradation goes unreported. The cost is a stream of qualified clicks that arrive at a dead end. Our published research on link health documents this distinction in more detail.
— Michael N.
Where a structured audit fits
Manual testing is appropriate for a single link or a small site. Beyond that, the time cost grows with the number of anchors, the number of programs and the age of the content. Affiliate Link Audit offers a Full Audit at 97 USD, a one-off fee, which combines manual and semi-automated checks, classifies findings by verified issue type, and delivers a prioritized action plan that separates clear fixes from items needing manual review. A Free Sample at 0 USD precedes it, so the evidence format can be assessed before purchase; the sample report shows the structure. Publishers can read how the service applies to their situation on the publishers page, or go directly to the Full Audit.
For measurement alongside the audit, the guide to GA4 affiliate tracking covers click-event rules, and the article on evidence-first affiliate tracking diagnosis sets out the wider order of operations. If the affected links sit on AMP pages, the AMP checklist applies first.
Prioritizing what to review first
When a site has more findings than time, ordering them by likely commercial exposure is more useful than working through pages alphabetically. Four criteria are commonly applied:
- Traffic to the page. Pages that still attract organic visits deliver the most clicks to a failing link.
- Position of the anchor. Links in introductions, comparison tables and calls to action receive more clicks than links in the final paragraphs.
- Classification. Broken items with an obvious replacement go first; Needs Attention items follow, since they require a decision before an edit.
- Program value. Where commission rates and cookie windows differ, links to the program with the stronger terms warrant earlier review. Rates and windows should be taken from each program's current published terms.
This ordering does not predict revenue. It ranks the order in which a publisher examines evidence.
Common mistakes when diagnosing a missing cookie
- Treating a 200 status as proof of health. Redirects to generic pages return 200.
- Testing only while logged in to the affiliate account. Some programs exclude or behave differently for self-referrals or authenticated sessions, so the result may not represent a normal visitor.
- Testing once. Redirect behavior can vary by region, device and time. A repeated test under different conditions separates stable defects from intermittent ones.
- Editing before classifying. Replacing a link that was merely Needs Attention can discard a path that was functioning for most visitors.
- Ignoring disclosure. Tracking repairs should not come at the expense of accurate disclosure of affiliate relationships and of cookie use, both of which the sources above treat as obligations.
FAQ
Why is my affiliate cookie not being set?
The usual causes are a missing or malformed tracking ID, a redirect that removes the parameter, browser or consent settings that restrict storage, and a merchant-side change such as a discontinued product. Tracing the redirect chain and checking the final URL separates these causes. The cookie itself is set by the merchant or network, so confirming it requires their reporting.
Can I check the cookie from my own website?
Not reliably. Browsers block frontend JavaScript from reading the Set-Cookie response header, according to MDN. What a publisher can do is inspect the URL, the redirect chain and the network responses in the browser's developer tools.
Does a 200 OK mean my affiliate link is working?
No. A 200 status shows that a page loaded, not that the page is the intended offer or that the tracking identifier survived. Redirects to a homepage or an unavailable product page also return 200, which is why such links are classed as Needs Attention or Broken after review.
Does the Affiliate Link Audit confirm that I lost commissions?
No. The audit detects commercially unhealthy links and provides evidence, such as discontinued products, homepage redirects and unverifiable tracking paths. It does not verify commission crediting or quantify lost income, and it does not change links; the publisher decides what to fix.
Sources
- Set-Cookie header, MDN Web Docs
- Amazon Associates Central: checking that links tag to your account
- Amazon Associates Central: 24-hour commission window
- Amazon Associates program policies
- FTC's Endorsement Guides: What People Are Asking
- What are third-party cookies? Google Privacy Sandbox
- Privacy Sandbox, Google for Developers
Recommended
- Publishers: 5 Tests to Find, Classify, and Fix Missing Affiliate IDs
- Affiliate Links That Stop Earning: Test, Classify, Prioritize
- Affiliate Link Rot: 200 OK Can Hide Revenue Risk for Publishers
- Shortened Link Not Tracking: Causes, Tests and Fixes
This article was produced with AI assistance and reviewed for accuracy. Findings language ("Broken," "Needs Attention," "Healthy") reflects Affiliate Link Audit's evidence-based classification system.