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 ;)

[Becker_ Rene]

Hi @Darryl Lee I don't want to repeat all the points that @__ Jimi Wikman made. I hope you don't mind. But of course I want to give you due answers :-)

> 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.

I see that point. A possible fix is to introduce templates for that.

> 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:

Thing is, I cannot do it centrally. So instead of "create folder and move on", I have to create and adjust.

> Are you saying you LIKED being able to link to a Folder and people instead landed on a PAGE?

Yes, because that's the whole point. I understand that that's not for everyone but until now you had a choice. That's gone now. Why did I like it? I pushed a user into a folder and it was clear from the start, that this is content inside a folder, not a sub-page. (also it was a bit easier in API because users couldn't mess around with it too much)

> But let's say if somebody had hidden their side nav, they wouldn't even know the folder existed at all?

I understand the approach but I've never seen that in real life unless someone was presenting or  annoyed by it, when editing / needed the space.

> Folders only existed in the side nav.

> Thing is: viewing the side nav is optional.

I think, we are running into a culture thing here. It's a complex topic, I'll try to keep it short but we can always expand it in 1:1s if you like.

I am from Germany and I have an audience that comes from physical folders, physical sorting and slowly transitions to digital structures (creatures of habit). The idea of using Meta Data to find and/or organize stuff is not really frowned upon but a concept that isn't embraced either. Having the clash between young and old isn't really helping either. Folders are a concept, being used for years and years, they can relate to, understand, work with. Meta isn't yet done being tansitioned to.

As I understand for US and US-like countries (only in terms of technical behaviour), they were really early adopters of Meta Data when Microsoft and similar made, neigh enforced, Meta Data and structure without hierarchy available (e.g. SharePoint and Teams). That's neither good nor bad - it's just different - and not likable for everyone.

My point is, since Atlassian behaves like a US-company, it enforces structures that do not fit all. If they want to keep their products versatile and attractive to the whole world, they will need to leave their bubble or at least give opt-out options for new features (not every, but many). Having being told to act a certain way by supplier isn't a thing either - you would wonder how many times I am asked to change some basic elements that Microsoft implements in Windows or if I can change SharePoints Download behaviour or if could change Jira Comment Security. And by "asked" I mean "demanded".

In my eyes, changing folders is redundant - but it might just be a cultural thing.

I hope I worded it in a way, that my point comes accross. I don't mean to be rude or to distinctive when it comes to talk about cultures. For me it's like some swear milk is good and some don't. Each have their reasons and a choice.

Hiding the sidebar? Mostly for users, that work with meta data, not with folders. And yes (don't ask why) for users it is a difference, if they see the pages on the left side or in the center of the page. It's just one of those things. Will they adjust? Yes - but it will take time until the younger people reign the media :-)

---

So as @__ Jimi Wikman said: It's not about adding a function, it's about removing a choice. It's a bit like live pages. Do I like it? Yes. Do I always want to use it? No. It has its time and its place.

---

[Malina Galvan]

This is nice, I just noticed though, today that my Child Items macros  are no longer working. Anyone else experiencing this? I was wondering if it was connected to this new feature for Folder's I found his week. Anyhow where can I report this issue I know this is not the correct spot so apologies in advance.