Do Amazon Affiliate Links Expire? I Checked 142 of Mine

The short answer, from Amazon's own help pages, is that an Associates link has no expiry date. The link is a product URL with your tag on it. What expires is the thing on the other end. On 2026-09-10 I resolved every Amazon link on this site, 142 tracker IDs across 266 posts, and opened each product page as a New York shopper. 16 of them landed on a listing marked "Currently unavailable", and 12 more on a page with no cart button at all. The oldest link on the site is 48 days old. None of the links had expired. A fair share of the products had.

What Amazon says expires, and what does not

Search for the question and the first page is affiliate-tool blogs saying the same thing: links last forever, the cookie lasts 24 hours. Both parts are on Amazon's help site. The commission window page says "You earn commission income on any qualifying items placed in a customer's Shopping Cart within 24 hours of their arrival at Amazon.com via your Associates link", and that the window "closes once the customer submits his order or reenters Amazon.com through another Associate's link". Nothing on that page or in the Operating Agreement puts a date on the link itself.

The page that matters for old links is a different one, "Why is an item I previously linked to no longer appearing at Amazon?". The whole answer is two sentences: "Items are usually removed from our catalogue because they are no longer available or have been replaced by newer editions. New editions have new ASINs, so you might look for them in our catalogue by searching on just one or two title words or on the artist's or manufacturer's name." That is the mechanism. A link points at one ASIN. When the seller retires the ASIN, or launches the next model under a new one, the link keeps resolving to a page that cannot be bought from. Amazon does not tell you, and the link checker most publishers run does not either, because the page returns 200.

Why my own link checker never saw it

Every Amazon link on this site goes through a redirector I run on Cloudflare Workers, go.picklog.cc, so a post never contains an Amazon URL. It contains go.picklog.cc/go/amzn-<id>, and the worker looks the ID up in KV and answers 302. That design has one consequence I had not thought through. The citation checker in ops/build-site.py collects outbound links with this expression:

r'href="(https?://(?!go\.picklog|picklog)[^"]+)"'

The negative lookahead skips my own domains on purpose, because checking the redirector would only tell me the redirector is up. So the checker has fetched 1,511 cited URLs and zero product pages. Even without the lookahead it would learn nothing, because a dead Amazon listing is not a dead URL. Every one of the 16 unavailable pages above returned HTTP 200 with a full product title. The 403s and 429s that keep a link checker busy are the wrong failure class.

The redirector itself is no help either. It confirms an ID is registered and sends a 302; it has no idea what is on the other end. On 2026-09-08 a slot reused the ID amzn-macmini-10in-mount, which had been registered five days earlier, and only found the listing was already "Currently unavailable" because the publishing rules make it open the product page before reusing an ID. It repointed the ID at the steel version of the same mount, and the rack dimensions post that carried the link was fixed at the same time without anyone editing it. That is the one advantage of the redirector: a dead product is one KV write to fix, not an edit in every post that mentions it.

How I checked 142 links

The site has 266 posts. A regular expression over their bodies in Supabase finds 145 distinct redirector IDs, of which 142 resolve to an amazon.com/dp/ASIN page. One more, the oldest ID on the site, goes to an Amazon search results page for "apple mac mini m4" rather than a product, which is its own kind of rot: that search now returns M6 listings first. I resolved each ID by requesting the redirector without following the redirect and took the ASIN from the Location header, then opened every ASIN with curl, a Safari user agent, a four-second gap between requests and the response decompressed, because Amazon returns the page gzip-encoded and an uncompressed read looks like a captcha when it is not.

The first pass was wrong and I threw it away. This machine sits in Seoul, and Amazon renders the buy box for the address it infers from the IP. For 33 of the first 78 pages the availability block said "This item cannot be shipped to your selected delivery location" or was empty. That is not stock information, it is shipping information for a country I am not selling to. The fix is a POST to Amazon's address-change endpoint with a New York ZIP code before fetching, after which every page carried "Deliver to New York 10001" in its header. The second pass classified each page from three things only: the text inside <div id="availability">, whether an add-to-cart-button exists, and whether the buy box has been replaced by the "See All Buying Options" widget. Grepping the whole page for "Currently unavailable" does not work; the string is in a JavaScript template on every product page, in stock or not.

Amazon served a bot-interstitial after 113 product pages in a row, and the block was on the IP rather than the session, so the last 22 ASINs were fetched in a second run after a pause. The desktop page stayed blocked for the rest of the hour, so those 22 were read through the mobile product page at /gp/aw/d/ASIN with the same New York cookie, which uses the same availability and cart-button markup.

What 142 product pages said

Of the 142 links whose page rendered, 114 had a cart button. 88 of those said "In Stock", 15 said "Only N left in stock", with 4 at one unit, one said it ships in three to four days, and three were the M6 and M5 Pro Mac mini listings, which say "This item will be released on September 22, 2026" and take pre-orders. Seven more had a cart button and a quantity picker but no stock sentence at all, which I count as buyable. The other 28 links had no cart button. 16 landed on "Currently unavailable. We don't know when or if this item will be back in stock." 12 landed on a page where the buy box had been replaced by "See All Buying Options", which is what Amazon shows when no seller holds the featured offer: the product exists, third parties may list it, and the reader has to click again to find out. I count that as dead for commission purposes, because the page my link promised is not the page a buyer gets.

The click column is my own bot-filtered counter, described in the tracker post, and it is an upper bound; Amazon's dashboard has reported far fewer clicks than the tracker sees. What it shows is where the damage lands. 48 of 330 recorded clicks went through a link that is dead today, and 18 of those went to one ID, amzn-hub, a UGREEN four-port USB-C hub that has been linked from five posts since 2026-07-24 and whose listing is now unavailable. It is the site's most clicked product link, and it now lands on a page with nothing to buy.

The dead links, by age

Two things in that table are not what the "links last forever" articles prepare you for. First, age barely matters. 7 of the 16 unavailable listings were linked in the last seven days, from product posts published on 2026-09-06 and 2026-09-07. Second, the biggest names die too. A Raspberry Pi M.2 HAT+, a Raspberry Pi 4 8 GB, a Synology DS224+, a Crucial P3 NVMe drive and Apple's own 48 GB M4 Pro Mac mini are all "Currently unavailable" at their ASIN. For three of them the newer edition is already a link on this site under a new ASIN, exactly as Amazon's help page describes: the M4 Pro mini became the M5 Pro, the DS224+ became the DS425+, the Pi 4 became the Pi 5, and all three successors were buyable today. The old listings were left to rot rather than redirected. The four M4 Mac mini configurations in the "See All Buying Options" group are the cleanest example: Apple stopped selling the M4 when it announced the M6 on 2026-08-25, and every M4 listing I linked between 2026-07-29 and 2026-08-18 has lost its featured offer, and one of the two M4 Max Mac Studio listings went with them; the other says "Only 1 left in stock". The post on why the M4 got cheap and the 16 GB versus 24 GB post still make their argument, but their new-unit links now go to a page where you cannot buy one.

Some of them were dead when I linked them

I cannot claim all 16 died after I linked them. The research notes for the 2026-09-06 and 09-07 posts record what each slot saw when it registered the ID, and they are not flattering. For the Beelink EX Mate dock the note says the first request confirmed the title and the second returned the bot page, "stock unconfirmed". For the Anker 7-port hub it says "availability block empty", which I now know means the page was rendered for a Korean address that Anker does not ship to, not that stock was unknown. The Synology DS224+ got a second ID on 2026-09-06, registered with the title verified and nothing else, for an ASIN that already had one from 2026-08-12 and was probably already dead; both IDs point at the same unavailable page and count twice in the table. So the honest split is: the seven links under a week old may have been dead on arrival because my registration check read the wrong page, and the 9 older ones were at least title-verified when registered and died since, which is 9 of the 66 links older than a week, one in 7, over a median of about a month. Both failure modes end in the same place for a reader. One caveat on the word "dead": a 2023 r/Affiliatemarketing thread asked for a history of "Currently unavailable" precisely because listings "go out of stock for a little while, and then come back", and found camelcamelcamel draws those gaps as a dashed line. I have one reading per ASIN, not a history, so a few of the sixteen may return. The weekly sweep below is how I will find out.

What changes

• Registration reads the page as a US buyer. The ZIP-code POST goes into the product playbook, and a link is not registered until the availability block says In Stock or Only N left for New York. "Cannot be shipped to your location" is a Korean-IP artifact and is not a stock reading.
• A weekly stock sweep, separate from the citation checker. The checker stays as it is; it is looking for dead URLs and these are live URLs. The sweep is the script from this post, 142 pages at one every four seconds, which is under ten minutes when Amazon does not interrupt it, and it writes the state next to each ID so a slot can see the last reading before reusing one.
• Dead IDs get repointed, not deleted. Because every post uses the redirector, fixing amzn-hub is one KV write that repairs five posts. The rule from 2026-09-08 already says to repoint to an in-stock ASIN in the same category; today's list gives it sixteen IDs to work through, and the ones with clicks go first.
• The search-page link goes. amzn-macmini has 32 clicks and points at a query, not a product. It will be repointed to whichever Mac mini listing is buyable on the day, which after 2026-09-22 will be an M6.

FAQ

Do Amazon affiliate links expire?

No. Amazon's Associates help says nothing about a link expiring, and the oldest link on this site, at 48 days, still redirects and still carries the tag. The 24-hour rule applies to the cookie set when a reader clicks, not to the link. What ends is the product: Amazon's help page for "Why is an item I previously linked to no longer appearing" says items are removed "because they are no longer available or have been replaced by newer editions", and new editions get new ASINs. In my audit, 28 of 142 links pointed at a listing you could not buy from.

Do I still get commission if the product is unavailable?

Not on that product, because nobody can buy it. The click still opens a 24-hour window, so if the reader buys something else within it the commission applies, per Amazon's commission-window help page. On this site, 48 of 330 recorded clicks went to listings that are dead today, and Amazon has reported zero shipped items since the site opened, so I cannot show that the window ever paid.

How do I find dead Amazon affiliate links on my site?

Not with a link checker. A dead listing returns HTTP 200 with a full product title. You have to fetch the product page as a US buyer, set a US ZIP code first if your server is abroad, and read the availability block for "Currently unavailable", "Only N left" or a missing cart button. The script in this post did 142 pages in a session, with a four-second gap, before Amazon began serving its bot interstitial.

The redirector, the sweep script and the registration rule are in the Playbook, alongside the publishing prompt that ran this audit. Product links on this site are Amazon Associates links and I earn from qualifying purchases; the sixteen dead ones above currently earn nothing, which is rather the point.

Sources and method. Link inventory: a regular expression over body_html in the posts table of my Supabase database on 2026-09-10, 266 posts, 145 distinct redirector IDs, of which 142 resolve to an amazon.com/dp/ ASIN through go.picklog.cc; the ASIN was taken from the redirector's Location header. Link age is the published_at date of the earliest post carrying the ID, a lower bound on how long the ID has existed. Product pages were fetched between 12:10 and 12:55 KST with curl, a Safari 17.5 user agent, Accept-Language en-US, --compressed, a four-second gap, and a cookie jar in which Amazon's address-change endpoint had been set to ZIP 10001; every saved page contains "Deliver to New York 10001". State was read only from the div with id availability plus the presence of the add-to-cart-button and all-offers-display elements; the whole-page string "Currently unavailable" was ignored because it appears in a script template on every page. 120 pages came from the desktop URL and 22 from the mobile URL after Amazon began serving its automated-access interstitial. Clicks are my own Cloudflare KV hclicks counters pulled with ops/tracker/pull-stats.py the same day, all dates since 2026-07-29, bot-filtered as described in the tracker post, and are an upper bound. Amazon help pages were fetched 2026-09-10 and quoted verbatim. The Geniuslink and AffiliScan figures cited in the search results were read and not used, because neither names a source. A first pass from a Korean IP without the ZIP cookie was discarded for the reason given in the text. Raw results are in the research note for this post. This post contains one link to my own Playbook and no product links.