Why don't the normal URL links keep working when pages are moved?

[ThomasW]

This question is in reference to Atlassian Documentation: Links

Why don't normal URL links keep working when pages are moved? This is just a basic requirement for documentation to be both maintainable & externally linkable.

No, my users don't want to use a special URL to link to, and there's no way I could consistently & reliably get them to do so.

As it is, moving & renaming pages (which are necessary to maintain the quality & – very importantly – the searchability of information) seem to result in broken links for users. This is just not remotely good enough.

[Felipe Carasso]

I agree with the "design flaw" vision. I never attempt to guess a URL from their space/page name and I often share links to other people before deciding that the page title needs reworking, or having temporarily created the page into my personal space then moving it to its rightful place.

I understand the usefulness of having hints about the page on the URL, but the side effects seem to overcome the advantages.

At least there should be an obvious way to share unique, immutable URLs to Confluence pages.

Maybe the page hints could be turned into harmless search parameters, so that if they no longer match space/title the URL still works?

[ThomasW]

Thanks Felipe -- that's exactly what I mean.

Wiki is meant to be "living documentation", but that requires links to still work when pages are renamed.

[Arien Huckeba]

The answers from Giles and Fred seem to miss the point.  This is a fundamental design flaw of Confluence.  The space name and page title should not be in the URL for exactly this reason - the URL should be like a hexadecimal, unique identifier for the page. No matter where you move the page or how you rename it, the URL should stay the same for the life of the page.  Putting the space name and page title in the URL is as backward as putting credit card number in the URL on a payment page.

Atlassian should fix this behavior, it is sub-par and it violates good web design principles.

[Nic Brough -Adaptavist-]

Actually, it's completely the right behaviour to allow humans to use a system.

It's a fundamental design flaw when systems fail to use terms their target audience do not understand. 

Failing to put a human-readable id like the space and page name in a url is just as dumb as assuming that we can remember a 15-digit credit card number (i.e. we never will)

Atlassian have nothing to fix, they are following good web design principles by making it easy for people to understand where they are.

[ThomasW]

@Nic Brough -Adaptavist- -- human-readable and search-friendly URLs are good, lack of ability for Confluence to automatically follow renamed/ moved pages is not.

Showing a 'Page Not Found' headline severely discourages users. Even if the moved page is linked below, many users in our org have already given up. This is severely deficient, and makes a barrier to usefully organizing & maintaining the Wiki.

Some easily possible solutions:

1. (At a minimum) Change the headline to 'Looks Like the Page Has Moved' and make the link to it a *lot* bigger to encourage users to proceed.
2. Since Confluence already has some tracking on moves/ renames, it could be possible to just redirect to the proper page.
3. (Best) If tracking information is not currently definitive, then add definitive tracking information. And get rid of the barrier page entirely.

Tracking information should be easily possible to make authoritative -- the only confounding factor would seem to be creating a new page of same name as a previously-deleted page. This could either be disambiguated numerically in the URL, or (as many Web properties do) a small unique identifier could be suffixed to all URLs.

We use Confluence as part of a significant software organization, and would like to consider expanding our use for in-depth product documentation.

However it would help if Atlassian took the needs of serious Wiki use seriously -- poor search and link rot when renaming pages are two of the key deficiencies.

Thanks,
Regards
Thomas

[Nic Brough -Adaptavist-]

But it does follow to moved and renamed pages, it only displays page not found when a page is no longer visible, or has been deleted.

I'd absolutely agree that there should be a redirect on the "page has moved" response.   (Maybe a few seconds with an option to click to cancel the redirect so I can go change my bookmarks)

[ThomasW]

@Nic Brough -Adaptavist- It displays 'Page Not Found' when pages are renamed for users linking from outside. (And possibly in some cases inside, eg. anchor links).

We have numerous bookmarks and links from outside Confluence, which need to keep working and not boldly tell users they've failed.

Like I have said repeatedly, the usability is not good enough. Large documentation bases need to be able to be reorganized, without showing users 'broken link' pages which they often won't proceed beyond.

Some example screenshots if you don't believe me:

And another:

[Paul Stallworth]

It may not meet your use-case exactly but the Comala Share It plugin keeps a list of all shared pages so it might be helpful in knowing what pages *could* be impacted by renames or moves.

The plugin's original intention is sharing outside of a private Confluence instance, so if yours is already public that might not make much sense.  

[Geof Edwards]

I am having the same issue as Thomas here.  I want to reorganize my confluence site which is littered with end points of links in jira stories. Annoyingly when I move a confluence age from space a to space b the link breaks but at the same time the 404 message does suggest to the user where to go. 

If it knows then why not just fix it? 

[Fred Bunting]

A "normal" URL must change if you move the page to a different space – just as it must change if you rename the page.  That's because the URL includes both the spacekey and title of the page.  

E.g. if a page in SPACE1 is titled Welcome Folks, then the URL would be http:://confluencesite/display/SPACE1/Welcome+Folks.  

But if you move the page to DIFFERENTSPACE, then the URL must change to  http:://confluencesite/display/DIFFERENTSPACE/Welcome+Folks.

That said, (1) no change of URL occurs if you are just moving the page to a different parent in the same space, and (2) this is only a problem when linking to Confluence pages from outside of Confluence.

Within Confluence, moving or renaming a page should not break links to it from other Confluence pages.  The exception is if you add a link to a page as a "Web Link" ... which users should not be doing.  Doing so only defeats a key feature of Confluence.

[Nic Brough -Adaptavist-]

And, if you move a page and someone lands on it because they have an old url, Confluence does the right thing and says "this page was moved to <new location>"

That more than answers the "basic requirement" because your obsolete urls still get you to the right page

[ThomasW]

Hi Nic: They get you to a "Page Not Found" page. Which, in the fine print, claims it may possibly be a renamed page.

I just want it to take users to the page, not tell them in the headline (which is all they will likely read) that it can't be found.

[ThomasW]

Thanks Fred for your answer. We wish to undertake maintenance – in all three regards of:

1. re-titling Pages to improve searchability (a big deficit here)
2. moving Pages within the heirarchy
3. also considering moving Pages/ Spaces as possible large-scale restructuring.

Apparently both the first and the third can have a substantial to severe impact on user bookmarks, external references & links.

Really any documentation needs to be maintained, but we feel this may be highlighting a weakness of Confluence; in that external links into Confluence are not transparently maintained.

As an aside, we have also seen issues of Attachments being lost when moving content between spaces. Which our Admins were not able to recover.

So yes, there seem to be some issues here.

[Giles B]

Hi Thomas,

If you're adding links as 'Web links' in the dialog, Confluence treats it as an absolute link and won't update those links for any reason. If you use Search, Recently viewed, or just paste in the URL of another page in your Confluence site, Confluence will add it as a relative link and will update the link when you rename the linked page.

[ThomasW]

No, I'm talking about linking from the rest of the world to Confluence. These turn into "Page Not Found" when pages are renamed in the process of maintaining content.

[Giles B]

Then, unfortunately, I'd say using the tiny URL is the only way to make sure they don't break.

[erik.unangst]

I am in a similar situation to Thomas. Right now I'm evaluating Confluence for my group. We are a small team of mechanical engineers and technicians.

This issue with broken links is one that I am trying to figure out before we migrate to Confluence. I just noticed today that some of my page urls have the page ID number in them, and some of them are the "pretty" urls which contain the page title instead. I've come to find out that certain characters in the title of the page (like "/" and "&") force the url to contain the page ID. It would be really nice to ALWAYS have the page ID url.

• Creating an outside link by copying and pasting the url with a page ID creates a robust link that doesn't break.
• Creating an outside link by copying and pasting the "pretty" urls into an email or other document creates a mess, because if the page title is changed, then the link is broken, although it does have a redirect, but that is hardly confidence inspiring.
• For now it seems like the best way to generate a robust link to a page is to click on the "share" button and "copy" the link that is shown there. Although I find it interesting that if you decide to complete the share process (rather than just copy the link) by entering someones name, filling out the message box "hey check out this page", and clicking share...it sends them an email with a link that can be broken if the page title is changed...sigh.
• Also, if you want to create a link to a comment, the easiest way is to click on the date of the comment, and copy/paste the URL. These links are also breakable if the url is not of the "page ID" variety. It's possible to use an anchor instead, but my team isn't going to remember to do this. I've not found a good solution for an easy, robust link to a comment, unless the page title has a special character in it.

I'm a mechanical engineer, so I'll admit I'm not savvy on the whole "readability" of the url. So, I could care less about its readability, and the same goes for the rest of my team. We use our page tree to navigate our space and the url is just "there", and it serves as a tool for generating a link. IMO this pretty url versus page url situation is hurting the usability of confluence - it breaks the most common method that folks are used to using for sharing links.

[Paul Stallworth]

Hi Erik!  Welcome to Confluence!

It seems you're pretty keen on the differences between URL types but I just want to point out you can get the page ID from the Page Information and always link directly to it with the following: <confluence base URL>/pages/viewpage.action?pageId=<pageId>.

For sending links outside of Atlassian tools the page Id is probably the most robust.  As you've already discovered you can also generate tiny URLs and/or use the Share button.  

[erik.unangst]

Thanks Paul, I am trying to make sure that everyone on my team utilizes the share button when sharing pages over email. It seems like that is the easiest way to share a robust link. 

Right now though, I am really struggling with how to create a robust link to a comment. Short of putting special characters in the title of my pages, there seems to be no way to do this. Do you have any suggestions? We really need a share button for comments...

It's also a problem with the "recently updated" macro. If you use this macro to look at comments, those comment links will break if the page title changes, but not if you have a special character in the page title prior to making the comment.

This pretty url thing is quite frustrating. I think it is my only major beef with confluence. I wish we had the option to disable it, because I otherwise love the platform.

[Paul Stallworth]

Hi @erik.unangst 

It sounds like you've read through this documentation page about creating links, specifically the section on links to comments, etc.

One thing I can offer you is that you can use a User Macro that might be able to create a permalink that you could then share out.  Does that sound like something that might be useful?

[ThomasW]

Thanks Steven. I'm talking about a normal URL link from outside to Confluence pages/ content;  using the plain "address bar" URL, not some special method.

[Steven F Behnke]

What is a "normal" link, for reference?