Reading time: 7 min read
Cleaning up orphaned items in SitecoreAI Experience Edge
Resolving stale content you can't see, still being served to production.
The Sitecore item is gone, so why is Edge still serving it?
You delete a page in Sitecore. It disappears from the content tree, it disappears from your site, and as far as your content team is concerned, it's gone. Except it isn't. Its child pages are still sitting in Experience Edge, still answerable by a GraphQL query, still very much live on your delivery layer. No parent, no way to find them in the authoring UI, but there they are.
Those are orphaned items, and until you go looking, you'd never know they exist. Let's talk about how they happen, why you should care, and the admin tool that cleans them up.
What is an orphaned Experience Edge item?
Quick refresher first. Experience Edge is the GraphQL delivery layer that serves your published content to your head, whether that's your Next.js site, a mobile app, or anything else consuming the API. Content lands there when you publish, and it's supposed to leave when you unpublish or delete.
An orphaned item is one that's still published in Experience Edge after it should be gone. The classic version of the story goes like this:
- A child item gets published to Edge without its parent.
- Later, the parent is deleted (or unpublished, or moved).
- Deleting the parent was supposed to cascade the unpublish down to Edge. But because the parent was never on Edge in the first place, the cleanup has nothing to match against, and the child gets missed.
The result is a child item that is stale and unreachable in authoring, but never actually removed from Edge. It just sits there, invisible to your authors and perfectly happy to answer a query.
How does an item end up orphaned?
Before we fix it, it's worth understanding how you get here, because it's easier to do than you'd think. Every one of these scenarios boils down to the same root cause: a child made it onto Edge while its parent did not. Here are the common ways that happens.
- Publishing a single item: You right-click a child item and publish just that one item, without its ancestors. The child goes to Edge, the parent stays behind.
- Publishing a subtree from the wrong starting point: You kick off a publish from a node partway down the tree with its subitems included. Everything below your starting point goes up, but the ancestors above it don't.
- Incremental or smart publishing: A changed child gets picked up and published while the parent had nothing queued to publish. The parent never gets pushed, so Edge only ever sees the child.
- Scripted or targeted publishes: PowerShell scripts, custom publishing logic, or targeted publish operations that act on specific items are easy places to accidentally publish a child in isolation.
- Restructuring and moves: You move a child under a new parent and publish the child, but the new parent hasn't been published yet. Or you reorganize a branch and the timing leaves a child on Edge whose parent context has changed underneath it.
None of these are exotic. They're the kind of thing that happens on a busy project with multiple authors and developers all publishing throughout the day. Then, weeks later, someone deletes the parent to clean up, the cascade misses the stranded child, and now you've got a ghost.
Why you should care
- You're serving stale content to production: A deleted page's children can still resolve through Edge. That's bad for SEO, and worse if that content was pulled for a reason: an expired campaign, outdated pricing, something legal asked you to remove.
- They're invisible: You can't see them in the content tree, so nobody notices until something surfaces one, and by then it's usually a surprise you didn't want.
- They can cause naming and path conflicts: The orphan is still occupying its old path on Edge. Create a new item down the road with the same name or in the same path, and you can end up colliding with a ghost. A query by path can resolve to the stale orphan instead of the item you just built, and good luck working out why when the culprit is something you can't even see in the tree.
- They quietly bloat your Edge footprint: Dead items you're still storing and still serving, for no reason.
The good news is prevention is largely handled now
Here's the encouraging part. A recent SitecoreAI platform fix addresses the situation that creates orphans in the first place. Per the SitecoreAI base image changelog, the issue where parent items weren't automatically published to Experience Edge, which is exactly what leaves child items stranded after the parent is deleted, has been fixed.
In plain terms, parents now get published to Edge alongside their children, so the "child on Edge without its parent" scenario is largely prevented going forward.
The fix only covers the publishing pipeline
One thing worth being clear on, because it trips people up: this covers publishes that run through the standard publishing pipeline. That's your UI publishes, scheduled publishes, and programmatic publishes that go through PublishManager or the Publishing Service. If you push content straight to Edge yourself, bypassing the pipeline with a direct Edge API call or a custom integration, there's no pipeline running to pull the parent along, so the fix does nothing for you there. Same goes for any code that deliberately publishes a child in isolation. The rule of thumb: if your code publishes a child, make sure the parent chain goes up too. The fix reduces accidental orphans, it doesn't absolve you of thinking about ancestors. And as always, test the behaviour on your own version before you rely on it.
But, and this is the important part, that fix doesn't retroactively clean up the orphans you already have. If your environment has been running for a while, you almost certainly have a backlog. For those, you need the tool.
Meet EdgeOrphans.aspx
Sitecore ships an admin page built for exactly this job: find the orphans, review them, remove them. You'll find it at:
/sitecore/admin/EdgeOrphans.aspx
You'll need to be logged in as an administrator to use it. Here's the full flow.
- Open the tool: Head to
/sitecore/admin/EdgeOrphans.aspxon your Content Management instance. - Scan: Click Find Orphans to kick off a scan against Experience Edge.
Watch the job: The scan runs as a background job, so it won't finish instantly. You can track it over at
/sitecore/admin/Jobs.aspx. Look forFindEdgeOrphansJoband wait for it to complete./sitecore/admin/Jobs.aspx- Review the results: Refresh
EdgeOrphans.aspxand it'll list each orphaned item with its ID, Parent ID, Cultures, Type, and Path. Take a minute here. This is your chance to see exactly what's going to be removed before you touch anything. - Remove: Once you're happy with the list, click Remove Orphans. This triggers a cleanup publish that removes the listed items from Experience Edge.
- Verify: Run Find Orphans one more time. A clean result confirms the cleanup did its job.
Two gotchas worth calling out
A couple of things trip people up here, so keep them in mind.
- One operation at a time: You can't scan and remove concurrently. Let each finish before starting the next.
- Remove acts on the last scan: The Remove Orphans operation uses the orphan list from your most recent Find Orphans run. So if the content tree has changed since you last scanned, scan again before you remove. Otherwise you're acting on stale data.
IMPORTANT: Always run Find Orphans immediately before Remove Orphans. It's a cheap habit that guarantees you're removing what's actually there right now, not what was there an hour ago.
The takeaway
Two things to walk away with. First, make sure you're on a base image that includes the parent auto-publish fix so you stop creating new orphans. Second, run EdgeOrphans.aspx once to clear out the backlog the fix won't touch, and then again after any big content restructure or bulk delete as a hygiene check.
It's the kind of problem that's completely invisible right up until it isn't. Ten minutes with this tool buys you the confidence that Edge is serving exactly what's in your tree, and nothing more.
