Confluence Folders Landing Pages

[#1]

To whomever implemented this thing of beauty:

YOU GUYS.

You should put this in a release note so you can take credit for it and get a bonus or promotion or however people advance inside of Atlassian.

So what you're looking at is the perfect answer to my "meh" response to the original introduction of Folders.

• They didn't really have permanent links - if you did manage to find the Copy Link option for a folder, going to that link redirected you to the first page in the folder.
• You didn't get a list of child pages/folders, so it was actually worse than creating a "parent page" with a pagetree macro.

This is GREAT new functionality for folders:

• Folders have their own unique URL and "landing page"
• They have graphical headers (removable and customizable)
• They list all TOP LEVEL pages and folders (also databases, whiteboards) in the folder
• You can also list the objects in a Grid!
  
  (Hrm, the Grid option does not stick, but maybe it's just as well as I would think they should instead show a thumbnail of the page header instead of that weird whiteboard-looking thing.)

But at any rate, great improvement! Whoever implemented it should get credit!

But um, also: Why was this not in any of the 3 different release notes?

• Community [sic] Release Notes 
• Atlassian Cloud Documentation blog posts
• Cloud Roadmap

Also not tracked by any of the third-party Atlassian release notes trackers:

• Cloud Changelog from @Jens Schumacher - Released_so 
• The Unofficially Unofficial Atlassian Cloud Changes Roadmap from @Patricia Francezi_iDev_ 
• Unofficial Atlassian Release Tracks Notes from me

C'mon, you create something great that is NOT AI-related and doesn't change existing how we work, and you don't let us know about it ahead of time?

I guess surprises can be nice, but still! Get your props!

[Liam Do - DevSamurai]

Totally agree, @Darryl Lee !

I noticed this update a few weeks ago and have been loving it. The new folder view and functionality are a huge improvement. Kudos to the team for pulling this off 👏

[Rob Hean]

10000% agree... this drastically improves the usefulness of folders!

[Jamie Zeidler]

Haven't seen this yet. Our sandbox also has the latest release track rolled out and does not have this functionality.

Maybe its some sort of limited beta feature release being tested on a limited user set?

It looks like a much-needed improvement to folders, so hopefully it will be something we will all soon get to enjoy.

[Tomislav Tobijas]

You should put this in a release note so you can take credit for it and get a bonus or promotion or however people advance inside of Atlassian.

Yes this!! 👆

I was also surprised by this when our interns showed me this. I was like... "Wow, this definitely wasn't announced anywhere, and yet it's such a cool improvement!"
And I've been waiting for this for a while now. There's just one more thing I'm missing now, and that's the folder 'emoji' - with that, the feature would be ideal 🙂

[Darryl Lee]

@Jamie Zeidler Ah right, I should note that while my screenshots are of a test site on Continuous Track, I am also seeing it on our production instance which is on the latest Bundled (not Preview) Release from July 14, 2026.

[Becker_ Rene]

I noticed it last week.

My thoughts: Why?

1) The pictures are atrocious (anyway to disable or at least replace them?)

2) Folders already had content ID and were supposed to get rid of an "in between page". Now we are back again.

And as always: No switch to turn the function off centrally (that I know of) and of course all folders that existed have been migrated automatically. And since there was no announcement, users pointed it out an we had to shrug because we weren't informed.

So all in all: We are back to where we started except for that we can have pages with the same name twice (which should've been able without folders anyway)

The way I see it:

Folders: great function

Folders that act like pages: We have pages for that

Sorry guys but I am not with you at all.

---

[__ Jimi Wikman]

My view on this is: https://jimiwikman.se/content/videos/my-videos/atlassian-videos-by-jimi-wikman/atlassian_teamwork-collection/confluence-playlist/confluence-folder-pages-explained-should-you-use-them-instead-of-parent-pages-r110/

Summary:

• Limited functionality for handling headers = broken design
• Unclear reason to use over pages with cards or page property reports.
• Complicates navigation flow (two functions now instead of one)
• Looks nice as new function
• Feels like a MVP experiment, not enterprise grade functionality.

[Rune Rasmussen]

I noticed this yesterday, but have also not seen any notice of this. Which is very much in line with Atlassian communication strategy of non-communication.

I'm on the same page as @Becker_ Rene on this one.

We're back to the old ways of having a parent page containing the /child items macro.

And we should be able to have pages with duplicate names. They have a unique ID after all, so the display name shouldn't matter. Not in 2026.

[Patricia Francezi_iDev_]

I saw in a production instance, but didnt have the time to figure out how to change it. 

anyway - yeah, I didnt see in the release tracks (none of them) - and we really need to keep pushing atlassian to centralize ALL even what they think are MINOR.... 

[Darryl Lee]

@Becker_ Rene and @Rune thank you for your opposing perspectives!

I think what I like is not having to add the /child or /pagetree macros. Or more importantly I don't have to explain that to my users.

My take is that this adds functionality and doesn't necessarily detract from the main purpose. A "bucket" for pages.

As I said, I really really disliked how linking to a Folder actually took you to the first page in that folder. That always felt wrong.

BTW, @Becker_ Rene in answer to your question, you can get rid of the image. It's the "Remove header" button shown in my screenshot:

I don't quite understand what you mean by this:

2) Folders already had content ID and were supposed to get rid of an "in between page". Now we are back again.

Are you saying you LIKED being able to link to a Folder and people instead landed on a PAGE? But let's say if somebody had hidden their side nav, they wouldn't even know the folder existed at all? That's one of the other problems with the previous behavior. Folders only existed in the side nav.

Thing is: viewing the side nav is optional.

This is one of my major gripes with how much functionality they've moved to contextual [...] menus. It makes the incorrect assumption that people can always see those menus. They CAN'T.

[__ Jimi Wikman]

@Darryl Lee You never had to add anything because you had a choice: 

1. Use a page as a landing page, styled to fit your space architecture and style.
2. Use a folder to group content that doesn't have a landing page.

This was the whole purpose of having a folder: Provide space architecture that did not require a landing page to avoid those unnecessary blank pages cluttering things up.

Now we have diluted that purpose, and folders are pages, but extremely limited pages that I can not do anything with. They do not fit the architecture purpose, and the style often does not match the rest of the space (since we have no control over headers).

For me, Folders now have no advantage over Pages anymore. There is no scenario where I would rather use a Folder than a Page. I can easily create a Page template that has the same function, but that I can actually style and work with.

I am not saying that the Folder pages are bad; I am saying that folders now are no longer folders in the sense that they were before. They are now index nodes rather than grouping nodes. Their function is no longer the same, and I fear this will make folders feel less useful.

On the upside, I can see the potential for a new app that adds the old folders without indexes, which I guess is good business for someone else.

Saying that navigation is optional does not compute for me. Information structure is still the number one cause for bad information architecture. I have spent many, many hours teaching people how to organise and classify information properly, and I can tell you that it all starts with the navigation, as it is the backbone of structured information.

This change is neither good nor bad; it is just altering the folder fundamentally in terms of purpose when building information architecture. 

Some people wanted to have grouping nodes, and they are now sad that that is gone. Others wanted indexing nodes, and now you have it.

We can still create empty pages like we did before the Folders existed if we don't like the indexing folder pages. It is not as nice, but it is what it is.

I can imagine that in a distant future we will have the option to choose i we want the folder to be indexing or grouping. I also see that we get the possibility to change the header as we can for pages and then all will be well with the world again ;)