Copied Confluence pages still link to the original
You copied a page tree, the pages all arrived, and then every link inside them opens the old pages. This is expected behaviour, it is not something you configured wrongly, and it is the single most common surprise when copying content in Confluence.
What is happening
When Confluence copies a page, it copies the page body as written. A link to another Confluence page is stored as a reference to that specific page, so the copy carries a reference to the original target, not to the new copy of that target.
So a two-page set behaves like this:
| Before | After copying both | |
|---|---|---|
| Page A links to | Page B | Page B, the original |
| Copy of A links to | — | Page B, the original |
Nothing is broken in the sense of erroring. The links work. They just point out of your copy and back into the source, which usually defeats the purpose of having made a copy.
Atlassian tracks this as an open request, CONFCLOUD-73312.
Why it matters more than it first appears
The immediate annoyance is small. The consequences are not, and they tend to arrive later:
- Edits land in the wrong place. Someone working in the new space follows a link, arrives in the old space without noticing, and edits there.
- Archiving the original breaks the copy. If the source space was copied so it could be retired, retiring it leaves the copy full of links to archived or deleted content.
- Permissions leak in confusing ways. A link into a space the reader cannot access produces a permission error rather than a useful page, in a space where they have perfectly good access.
- It is invisible until someone clicks. The copy looks complete. There is no warning, no report, and no list of which links point outside.
What Confluence does and does not repoint
| Element | Repointed by a native copy? |
|---|---|
| Links to pages inside the copied set | No. They continue to open the originals |
| Links to pages outside the copied set | No, and correctly so. These should stay as they are |
| Attachments on the copied pages | Yes, copied with the page |
| Embedded images stored as attachments | Copied, though the reference may still resolve to the source attachment |
| Macros that reference a specific page, such as Include or Excerpt Include | No. They keep pulling content from the original |
| Labels, page restrictions | Yes |
| Comments, version history | Not copied at all, by any method |
The macro row is the one people miss. An Include macro that still points at the source means the copy displays the original's content, so edits to the original silently change the copy. That is harder to spot than a link, because nothing about it looks like a link.
How to fix it
Find them first
Before deciding on a method, find out how many you are dealing with. In the new space, search for links pointing at the source space key. Confluence search supports a space filter, and the source space key is the string you are looking for in link targets.
For a handful of pages, open each one, use the browser's find on the rendered page, and hover the links to see where they go. For a hundred pages, do not do this by hand.
Option 1: edit them by hand
Open each page, click each internal link, re-pick the target in the new space, publish.
Honest about when this is right: under about twenty links, this is quicker than anything else, and you get to see each one. Above that the error rate climbs, and the links you miss are the ones nobody clicks until months later.
Option 2: copy the whole space at once, with an app
The reason links cannot be repointed afterwards by Confluence is that the information needed is gone: once the copy exists, nothing records which new page corresponds to which old one. A tool that does the copying can keep that map as it goes, and then rewrite each link to its counterpart.
That is what makes this a copy-time problem rather than a cleanup-time one. It is also why "copy first, fix links later" is harder than it sounds.
What to check in any app that claims to do this:
- Does it repoint macro references too, not just plain links? Include and Excerpt Include are where the silent errors live.
- Does it leave external links alone? A link to a different site, or to a space you did not copy, should not be rewritten. Over-eager rewriting is its own bug.
- Does it report how many it changed? A number you can sanity-check beats a claim that it worked.
- What happens if it stops halfway? A half-rewritten space is worse than an un-rewritten one, because now you cannot tell which links were handled.
Clone Space for Confluence builds the page map as it copies, rewrites links and macro references to point inside the new space, leaves genuinely external links alone, and reports the count of references it changed. It is free for up to ten users.
Option 3: decide you do not need it
Worth saying, because it is sometimes the right answer. If the copy exists as a point-in-time snapshot that nobody will edit, links pointing at the live original may be exactly what you want. The problem only bites when the copy is meant to be a working, independent space.
Frequently asked
Does Confluence Cloud ever repoint links automatically?
Not when copying. It does update links when you move or rename a page, because the page keeps its identity. Copying creates a new page with a new identity, and the original references are left pointing at the original.
Is this different on Data Center?
Data Center's native Copy Space, available since version 8.3, handles the whole-space case including link rewriting within the copied space. The feature has never come to Cloud, which is why the Cloud request is still open.
Will a space export and re-import fix it?
Exporting and importing a space is a different operation with its own constraints, and it is not a general answer to copying a space within the same site. For most teams it introduces more problems than it solves.
What about links in page properties or tables?
They are stored the same way as any other link in the page body, so they behave the same: copied as written, pointing at the original.