Moved page with folders to a new space - the child pages in folders were invisible

[Siimon Härm]

So - found a bug. 

Moved a page from one space to another.

The page itself appeared in the new page, but the child pages didn't. 

Quick investigation showed that in content manager there is a the main page, but clicking dropdown didn't show any pages.

refreshing page and ticking the box near the main page shows +N pages

clicking dropdown again shows no pages and tick shows +0 pages. 

the pages were not orphaned and could be found via MCP

going to the page didn't show it in the UI - but moving it via contextual menu allowed it to be put under main page and show in UI.

Moving 40+ pages like this didn't seem like an option.

Tried seeing child pages via /child-pages block - found that all pages are 2+ levels deep. Meaning skipping something. Found that the skip was folders.

Using Gemini and Claude found a solution - use content -> reorder to move folders (and pages) to re-index them. Folders appeared in UI and pages were visible in the tree too. 

Same happened in another space, but not sure if folders were involved or just simply moving it was a problem. 

Previous tree structure -> Target tree structure

Content/page/page/folder or page -> Content/page/folder or page

Please see if it's reproducible and if it's a bug. 

[Sami Shaik]

@Siimon Härm ,

@Arkadiusz Wroblewski is right that this goes to Support, and @Mihai_LeanZero  has the one tracked piece (CONFCLOUD-80330 explains why the Child pages macro skipped the folder level). Two things to add so the ticket lands as a bug rather than a how-to, and one documented cause to rule out first.

Rule out drafts before you report. Confluence cannot move unpublished content between spaces; a draft nested under a page or folder you move is not relocated, it is left behind in the source space with no warning. If any of the "invisible" pages were drafts or live-edit pages that had never been published, that part is by design, not a bug, and they are still in the source space's content manager. The published ones that went missing from the tree are the bug.

What you found is worth naming precisely for Support. The pages were not orphaned (you found them by ID and could move them individually), the tree showed +N and then +0 for the same node, and Content, Reorder repaired the tree without touching the pages. That pattern says the pages moved correctly and the tree index for the folder level did not get rebuilt during a cross-space move; Reorder forces the rebuild. Put those three facts, the source and destination space keys, the moved page ID, one child page ID that was invisible, and the timestamp of the move into the ticket. That is enough for them to pull the move event on their side, and it is the difference between a two-week ticket and a two-day one.

For anyone landing here with the same symptom: Siimon's workaround holds. In the destination space, Content, Reorder, then drag the affected folder (or any item) one position and back; the tree rebuilds and the children reappear. Do not re-move 40 pages by hand. And before any cross-space move of a tree that contains folders, publish every draft under it first, because those will not travel.

[Arkadiusz Wroblewski]

Hello @Siimon Härm 

You should address that with support.atlassian.com 

Best,

Arek🤠

[Mihai_LeanZero]

Folders are the common thread here.

CONFCLOUD-80330 covers the child-pages part directly. The Child Pages macro cannot take a Folder as parent, and it errors outright when a page is converted to a folder after being set as one. Gathering Impact, 20 votes, open since December 2024. That accounts for what the /child-pages block did, though not for the tree itself.

The tree symptom I could not find tracked. Searched CONFCLOUD for child pages going missing after a move and the near matches are all about other things, so it reads as unreported rather than known.

The reorder fix is the useful clue. Reorder rewrites position, so if that alone brings them back the content was intact and the tree index was stale. Support will want precisely that: both space keys, roughly when the move happened, and that a reorder cleared it.