Skip to content
Blog ·Deep dive··8 min read

What the affiliate link checker checks (and why each matters)

Most free checkers only verify HTTP status. That misses 80% of how affiliate links actually fail. A walkthrough of the five checks Affiliyo runs, what each catches, and what still falls through.

Almost every free affiliate-link checker on the web does the same thing: it sends an HTTP request to your URL and checks whether the status is 200. If yes, "your link works." If no, "your link is broken." That binary verdict catches less than 20% of the ways an affiliate link actually fails in production.

This post walks through the five checks our free affiliate link checker runs on every URL you submit, what each one actually catches, and the failure modes that still fall through (and require ongoing monitoring to spot).

1. HTTP reachability

The most basic check: does the URL respond at all? We send a HEAD request first (cheap, just headers). If the server rejects HEAD (some Cloudflare-fronted retailers do, treating it as a bot signal), we fall back to a GET. The server's status code is the headline answer.

What it catches:

  • 404 Not Found: the product page has been removed entirely
  • 410 Gone: explicitly deprecated by the merchant
  • 500-series errors: server-side breakdown
  • DNS failures: the domain itself no longer resolves
  • SSL handshake failures: cert expired or invalid, browsers will block the visitor before they ever see the page

What it misses: the most common silent failure, a soft 404. A page that returns 200 OK but displays "currently unavailable" or "this item is no longer sold." HTTP status checks pass; conversion does not.

2. Redirect chain trace

Affiliate URLs almost always redirect. Sometimes once, sometimes through 5+ hops. We trace the full chain (up to 8 hops) and record the final destination. The hop count and final URL are both reported.

What it catches:

  • Excessive redirect chains (4+ hops) that fragment cookie attribution and break some networks
  • Domain drift, where a link that started at amzn.to/xyz ends up at example.com/some-error-page
  • Aggregator middlemen (Geniuslink, RewardStyle) that may strip your tag mid-chain
  • Locale-mismatch redirects on Amazon (your US -20 tag triggers a redirect to amazon.de which doesn't honor your tag)

What it misses: redirects that work fine for crawlers but get blocked for actual visitors (rare, but happens with CAPTCHA gates and aggressive bot-protection). The check sees a "successful" redirect; a real visitor sees a CAPTCHA.

3. Affiliate tag survival

After tracing the full chain, we inspect the final URL for known affiliate tag parameters. Amazon uses tag, Awin uses awinaffid or clickref, ShareASale uses afftrack, Impact uses irclickid, CJ uses sid, etc. We check against the curated parameter list and report whether ANY recognized tag survived.

What it catches: the single biggest silent revenue leak in affiliate marketing, tag stripping. A page that loads fine but no longer carries your tracking parameter in the final URL. The network sees the click as anonymous traffic. Your commission silently goes to zero. See the tag-stripping pain-point for the deeper mechanic.

What it misses:

  • Click-ID-based attribution (Impact, CJ) where the cookie is set BEFORE the final URL, even if the tag is missing visually
  • Server-side attribution via logged-in user matching (Amazon does this for signed-in customers regardless of URL tag)
  • Whether the tag is VALID: we confirm a tag exists, not that the merchant currently accepts it for new commissions

4. SSL certificate validity

For any HTTPS final URL, we do a TLS handshake and read the certificate. We report validity, expiry date, and issuer.

What it catches:

  • Expired certs (browsers show a full-screen warning that stops 95% of visitors)
  • Certs that don't match the hostname (browser warning, conversion-killer)
  • Certs issued by untrusted CAs (rare, but happens with discount cert authorities)
  • Cert near-expiry (within 14 days): heads-up before it actually breaks

What it misses: TLS handshake failures specific to the visitor's browser/OS combination. We test from a modern Chromium configuration; a visitor on a very old Safari might hit issues we don't see.

5. AI page-content verdict

The differentiator. We fetch the rendered page, extract its visible text (stripping scripts and styles), and pass the first 800 characters to an LLM. The model returns a structured verdict: is_available, status (in_stock / out_of_stock / removed / region_locked / unknown), a one-sentence reason, and a confidence score.

What it catches:

  • Soft 404s that HTTP checks miss ("currently unavailable" with status 200)
  • Region-locked products ("not available in your country")
  • Discontinued listings still rendering ("this item is no longer sold")
  • Variant-level stockouts (the parent product page renders, but the specific color/size you linked is sold out)
  • Brand changes: the page loaded but talks about a different product than expected

What it misses: anything that requires JavaScript to render. The check reads server-rendered HTML only. Single-page-app product pages (rare for retail) may not surface availability state in the initial HTML.

What still falls through

No automated check can verify these in 5 seconds:

  • Network-side attribution policy changes. The merchant may have changed payout rules without changing the URL or page.
  • Cookie-window expiry on the visitor's side. Outside our visibility.
  • Account-suspension state on YOUR end. We check the link; we can't check whether the network has frozen payouts to you.
  • Geo-specific behavior. We check from one IP; a visitor in a different region may see different content.
  • Time-of-day stock fluctuation. The link checks healthy at 10am; sold out by noon. Only ongoing monitoring catches these.

For the first four, you need network-dashboard visibility. For the last (time-fluctuating state), you need a monitor that runs throughout the day, not a one-off check. That's the gap our paid monitoring fills: same five checks, but on every link, three times a day, with email alerts the moment something flips.

When to use one-off checks vs ongoing monitoring

Use the one-off free checker for:

  • Verifying a new affiliate URL before you publish it
  • Diagnosing a specific link a reader complained about
  • Quickly seeing what your tag situation looks like on a single piece of content
  • Testing whether a managed-URL setup is forwarding correctly

Use ongoing monitoring for everything else. The five checks above all assume "right now"; affiliate links rot over months and years. A check that ran clean six months ago tells you nothing about today.

Run any URL through the five checks in 5 seconds. No signup.

Try the free affiliate link checker

Have 10 links? Start monitoring them free.