Before touching settings, work out which of three things is actually broken: the link string itself, the page it points to, or the service hosting the redirect. Most "short link not working" reports turn out to be one of those, and each has a different fix.
Step 1: rule out a copy or typing error
Short links are dense strings of random-looking characters, which makes them easy to mistype or truncate when copying from a printed flyer, a slide, or a text message that wraps the URL across two lines. Retype the link by hand character by character rather than trusting a copy-paste, especially if the source was an image, a screenshot, or handwritten notes. Check for a trailing character that got swept up by accident, a space in the middle from a line break, or a lowercase L mistaken for a capital I. This sounds trivial, but it fixes a surprising share of reports, because what looked like a broken link was really just a bad copy.
Step 2: test the redirect on its own
Open the short link directly in a private or incognito browser window, separate from wherever you first tried it. This removes cached DNS, saved autofill, and any browser extension that might be interfering, and it tells you immediately which side of the problem you are on. If the redirect fails at this stage, with a "link not found," "expired," or blank error page coming from the shortener's own domain, the problem is upstream at the link itself. If the redirect succeeds and sends you somewhere, but that somewhere shows a 404 or an unrelated page, the redirect is doing its job correctly and the problem is downstream, at the destination. A proper walkthrough of this check is in how to test a redirect, including what to look for in the browser's network tab if you want to see the actual HTTP status code instead of guessing from what renders.
Step 3: check whether the destination page still exists
This is the most common actual cause once typos are ruled out, and it has almost nothing to do with the shortener. Websites get redesigned, blog posts get deleted, product pages get replaced, and Instagram bio links quietly point at content that moved months ago. The shortener faithfully forwards every visitor to the URL it was given. If that URL now returns a 404, the shortener isn't broken. It's doing exactly what it was configured to do. This pattern has a name, link rot, and it is the reason a short link that worked fine for a year suddenly stops working with no configuration change on your end. The fix is to update the destination the short link points to, not to recreate the short link.
Step 4: check the shortener account and custom domain
If the link fails at the redirect stage itself rather than at the destination, check three things on the account side: whether the link or the account it belongs to expired or was deleted, whether a free plan's link limit or retention window has been exceeded, and, if you are using a custom domain instead of the shortener's default domain, whether that domain's DNS records are still correctly pointed at the service. Custom domains are the more fragile of the two, because they depend on records set up once and then left alone, and a renewal lapse, a nameserver change, or an unrelated DNS cleanup can silently break every link on that domain at once even though nothing about the links themselves changed. Setting this up correctly the first time is covered in how to point a domain with DNS, and it is worth revisiting that setup any time a custom domain stops resolving without an obvious cause.
Step 5: rule out a safety or spam flag
If the link opens to a warning page instead of a 404, on either your device or a friend's, that is a different problem with a different fix: the destination or domain has been flagged as unsafe by a browser, a platform, or a spam filter, rather than being technically broken. This shows up as messages like "this link may be unsafe" or a platform refusing to open it at all, and it is common enough with shared shorteners that it gets its own full breakdown in why is my link flagged as unsafe. Do not treat a safety warning the same way you would treat a 404. A 404 means the content moved. A safety flag means a reputation system made a judgment about the domain, and the fix runs through that platform's review process, not through your link settings.
Step 6: check if it's a device or network issue, not the link
If the link works for you but not for the person reporting it, ask what device and network they were on before assuming the link itself is at fault. Corporate networks and some mobile carriers block known shortener domains outright as a blanket policy, which has nothing to do with whether your specific link is configured correctly. In-app browsers inside Instagram, TikTok, or Facebook sometimes mishandle a redirect chain differently than a standalone browser does, particularly with links that bounce through more than one hop before reaching the final destination. A stale DNS cache on the reporting device can also make a link look dead for them while it works everywhere else. Asking them to switch networks, try a different device, or restart their browser isolates this quickly, and it saves you from chasing a fix on the backend for a problem that was never on the backend.
It also helps to ask when they last tried it. A link that broke an hour ago and a link that has been broken for three weeks point to different causes: the first is more likely a temporary DNS or service hiccup, the second is almost always a destination that changed or an account issue that has had time to sit unnoticed.
Fix it, then update everywhere it was shared
Once you have identified the actual cause, match the symptom to the fix rather than guessing:
| Symptom | Likely cause | Fix |
|---|---|---|
| Shortener's own domain says "link not found" or "expired" | The link was deleted, or a typo in the copied string | Retype the link by hand, or recreate it if it was genuinely removed |
| Redirect works but the destination shows a 404 | Link rot: the destination page moved or was deleted | Update the destination URL the short link points to |
| Nothing loads, spinner or timeout on a custom domain | DNS records for the custom domain are missing or misconfigured | Re-check the DNS records against the setup guide and re-verify |
| "This link may be unsafe" warning | The domain was flagged by a browser or platform reputation system | Request a review through that specific platform, do not just recreate the link |
| Works on wifi, fails on mobile data, or vice versa | Carrier-level blocking or a stale DNS cache on one network | Test on a different network, flush DNS cache, retry |
The step people skip is updating every place the old link already lives once the real fix is in: print materials, an Instagram bio, an old email signature, a QR code already printed on packaging. A short link's whole value is that it gets reused everywhere without being edited. That's also exactly why one unnoticed break can quietly cost weeks of dead clicks before anyone reports it. If a link needs to survive on printed material long term, building it with QR code best practices for print in mind from the start reduces how often this cycle repeats.
What a link tool with proper monitoring gives you
Raydar links carry click analytics by default, which means a link that suddenly drops from its normal daily click volume to zero is visible in the dashboard before someone emails you to say it is broken, rather than after. That does not replace the diagnostic steps above, since Raydar still cannot know that your destination page returned a 404 unless you check it, but it does turn "how long has this been broken" from a guess into a number you can read off a graph.