Sooner or later a Confluence admin goes looking for one thing: a list of the broken links in a space, so they can fix them before a reader hits a dead end. You open the admin, look for the report, and it is not there. This guide shows you how to hunt broken links down for free with the tools Confluence already gives you — and, just as importantly, where each free method quietly fails.
No — and it is worth being honest about that up front, because it is the reason you could not find the report. Atlassian's own support documentation on validating links is candid that Confluence has no automated way to validate them, and that an administrator has to open pages one at a time and check each link by hand.
This is not an oversight you are imagining. There has been a feature request asking for exactly this — a native link report or link validator (CONFCLOUD-65867) — and Atlassian declined it. So this is not a gap that is about to close on its own: Confluence Cloud has no screen that lists your broken links, and you assemble that picture yourself.
Every method below gets easier once you split the problem in two, because the two kinds fail for different reasons and need different checks:
Keep this split in mind, because most free tools only do the first kind well. The internal kind is where the silent damage happens.
The method Atlassian's support article actually recommends is the manual one: open a page, click every link on it (middle-click to open each in a new tab so you keep your place), note the ones that error, and move to the next page. It is completely free, it needs no tooling, and for a small space of a dozen pages it genuinely works.
The honest catch is that it does not scale. Twenty pages is an afternoon. Two hundred is a project nobody finishes, and because it relies on a human noticing every dead link on every page, it is exactly the kind of task where attention drifts and links get missed. It is the right first move for a tiny space and the wrong one for a real one.
For anything bigger, the standard free approach is to export the whole space and let a tool read the links for you:
.zip of the space as static HTML pages.<a href> with a pattern like href="([^"]+)", then dedupe the list; or200 OK.This is the best free method for one specific job — external links — and you should use it for that. But be clear-eyed about its three blind spots:
This is the part most link audits miss, and it is the most important thing to understand about link rot in Confluence.
Deleting a page does not fix — or even flag — the pages that link to it. There is no warning when you delete a page that six other pages point at it. There is no notification to the owners of those six pages. There is no report afterward. The links just quietly become dead ends, and you find out when a reader hits the error and (if you are lucky) tells you.
The mechanics are worth knowing so you can reason about your own space:
This is the case the export-and-crawl method in Method 2 is weakest at, because the broken thing is not a URL that fails to answer — it is a live, healthy-looking page that happens to contain a pointer to something that no longer exists. That is the quiet, structural link rot a busy space accumulates, and it is invisible to every tool that only checks whether external URLs respond.
It is the obvious idea, and it does not work — for a reason worth knowing. Confluence search indexes the text on your pages, not the health of the links inside them. There is no query that means "show me pages that link to something which no longer exists," because that is not a property search records. Search will cheerfully return a page whose every link is broken, because the words on the page are still perfectly readable. Search finds content; it never finds link status.
If you are comfortable writing a bit of code, the most thorough free route is to build the inventory yourself with the Confluence Cloud REST API:
<a href>. Internal ones are Confluence markup — <ri:page> for a page reference and <ri:attachment> for a file.It is the right approach, and it is also where the fiddliness lives. Expect to spend most of the effort on the edges, not the happy path:
/display/SPACEKEY/Title URLs, and cross-space references need more than the current space's inventory to judge — get one wrong and you either miss a real break or cry wolf on a healthy link.Whichever method you pick, the result is a snapshot. It is true the minute you run it and stale the minute someone deletes the next page. Re-exporting, re-crawling, re-resolving — that recurring cost is the real reason most teams run a link audit once, feel virtuous, and never run it again. In between, the links keep rotting quietly, and the internal ones rot fastest, because nothing in Confluence is watching them.
Disclosure — this is my app. The manual audit above got tedious enough to keep re-running that I built a small Forge app for the one part it is worst at — the internal links that break silently: Link Health - Broken Link Checker for Confluence.
You pick a space and click Scan now. It reads that one space on demand and reports the broken internal links — references to pages that no longer exist. It groups the results by the dead target, so a retired page that six others still point at is one fix to make, not six identical rows to wade through, and every row deep-links straight into that page's editor so going from report to repair is one click. It uses read-only Confluence scopes (read:space, read:page) plus the app's own storage (storage:app) for its per-space ignore list, so it never writes to your Confluence content, and it is admin-only.
It is deliberately honest about its own limits, and states them on screen next to the counts: it does not probe external URLs, it does not check attachments, and some links are skipped or left unverified — so an empty queue is never sold to you as a clean bill of health. Those checks (external links, attachments) stay in the manual methods above; this app does the internal-link case, well. It also runs entirely on Atlassian: the app ships with no external permissions and no remote services, so nothing about your space leaves Atlassian.
Pricing is per user, per month, billed through Atlassian's own cloud billing: free for up to 10 users, then a low per-user rate that declines as you scale. Once a site passes the free tier, the first tier's rate applies to every user up to 100; above that, each tier's rate applies to the users in that tier, which is Atlassian's standard model. Those are directional prices, not a promise — see the About page for the current ladder.
No. Atlassian's own support documentation is candid that Confluence has no automated way to validate links, so administrators have to open pages one at a time and check each link by hand. The feature request for a native link validator (CONFCLOUD-65867) was declined, so this is not a gap that is about to close on its own: Confluence Cloud has no built-in report that lists your broken links.
Export the space to HTML (Space Settings → Content Tools → Export → HTML), then either open the export in a text editor and pull out the links with a regular expression, or point a free external link-checker crawler at it, and test what comes back. That catches many external URLs. The catch: it does not reliably catch internal links to Confluence pages or attachments that were deleted, and it can't reach content behind space restrictions.
Because deleting a page does not fix — or even flag — the other pages that link to it. The reference simply becomes a dead end, with no notification and no report. A page linked from six other pages can quietly break all six at once, and you only find out when a reader hits the error.
Not directly. Confluence search indexes the text on your pages, not the health of the links inside them, so there is no query that returns "pages that link to something which no longer exists." Search will happily return a page whose links are all broken, because the words on it are still there.
External links point to other websites and break when that site changes or goes down — you check them by requesting the URL. Internal links point to other Confluence pages or attachments in your instance and break when that target is deleted (archiving a page does not break links to it, and moving one does not break the links Confluence manages to it). They fail for different reasons and need different checks; most free crawlers only handle the external kind.
Yes. Any page, blog post, or attachment that linked to the deleted item now has a dead link, and Confluence gives you no built-in list of them. This is the single biggest source of quiet link rot in a well-used space, and it's the case the manual export-and-crawl method is weakest at finding.