Stale Referenced Content in SitecoreAI

You update an image on an item, publish it, and query Experience Edge. The new image is there. But the page that references that item still serves the old one, no matter what else you publish. The fix is a single setting that is off by default.

Consider two templates, Article and Author. An Article points at one or more Authors through a TreeList, and the article page renders each author's details, including their headshot.

Article
└── Authors: TreeList
    ├── Author A
    └── Author B

A content editor changes the headshot on Author A and publishes it. Querying the Author directly returns the new image. The Article page keeps returning the old one.

Publishing the Author with Current Language, All References and Include Related Items makes no difference. Only manually republishing the Article works.

The Article directly references the Author, so we'd assume Experience Edge would refresh the Article on its own. Wrong.

Experience Edge isn't an exact copy of your content database. With snapshot publishing, an item's rendered layout is generated at publish time and stored on Edge. The Article's snapshot has the old headshot baked in, and nothing tells Edge to bake a new one.

For Edge to regenerate the Article when an Author changes, it needs the relationship stored in the opposite direction:

Article references Author --> Experience Edge records Author has Article as a dependent

Once that dependency exists, publishing the Author pulls the Article into the publishing pipeline and its snapshot is rebuilt with the new image. This resolves recursively until no dependents are left.

If that seems like a circular dependency, it's not. The reference still only goes one way (Article to Author); Edge just keeps a reverse lookup. A real cycle needs the Author to point back at the Article (say, through a Featured Articles field), and those do cause trouble. More on that below.

But there's a catch.

Dependencies through link and list fields (Treelist, Multilist, Droplink, Droptree) are NOT computed by default; that's controlled by ExperienceEdge.ComputeContentDependencies.

Add a config patch to your solution:

<?xml version="1.0" encoding="utf-8"?>
<configuration
  xmlns:patch="http://www.sitecore.net/xmlconfig/"
  xmlns:set="http://www.sitecore.net/xmlconfig/set/"
  xmlns:role="http://www.sitecore.net/xmlconfig/role/">
  <sitecore role:require="Standalone or ContentManagement or XMCloud">
    <settings role:require="XMCloud">
      <setting
        name="ExperienceEdge.ComputeContentDependencies"
        set:value="true" />
    </settings>
  </sitecore>
</configuration>

Flipping the setting only changes how dependencies are calculated during FUTURE publishes. For content already sitting on Edge, there's still no record of who depends on what.

So after enabling (or disabling) it, republish the site in every language. That's what builds the dependency data.

To confirm it worked:

1. Update and publish an Author
2. Check that the dependent Article shows up in the publishing operation
3. Query Edge for the Article's layout and look for the new image

Include Related Items looks at the item you're publishing and pulls in what it references. We need the reverse; the Author doesn't reference the Article.

Forward relationship:
Article -> Author

Required publishing fan-out:
Author -> every dependent Article

That reverse lookup only exists if Edge computed and stored it ahead of time, which is exactly what ExperienceEdge.ComputeContentDependencies turns on. Keep Include Related Items checked, just don't expect it to do this job.

You thought you'd get something expensive for free?

The inescapable laws of economics dictate that expensive things shall not be doled out willy nilly.

With the setting on, publishing one item drags every dependent item into the pipeline, and those can have dependents of their own. Publish an Author referenced by 150 articles and you republish 150 Articles, whether they changed or not.

Now swap "Author" for a taxonomy tag used on thousands of pages, or a shared call to action, or a site settings item. One small edit turns into a very long publish.

Before you turn it on, look at what your link/list fields point at:

• Taxonomy items referenced by hundreds or thousands of pages
• Global header / footer content
• Navigation items and site settings
• Circular references (A points at B, B points back at A)
• Anything referenced through several layers of related content

Sitecore specifically calls out removing cyclic references, since they make the dependency calculation needlessly expensive.

One more thing. Dependency resolution can sweep up an item another content editor is halfway through editing, just because someone published something related. If you don't have a workflow, this is your sign. Even a basic Draft / Publish workflow keeps unfinished content off of Edge.

Everything above is about snapshot publishing.

With Edge runtime publishing, layout structure and datasource references are stored separately and assembled at delivery time. Publishing a datasource doesn't republish its dependents, and that's on purpose -- avoiding these cascades is the whole point of that model.

So figure out which publishing model you're on before you go hunting for a missing setting.

A few more things to rule out:

1. Is the field type supported? The list lives in ExperienceEdge.LinkDependentTypes.
2. Is the setting actually true in the effective config (and not just in your repo)?
3. Did you republish the site after changing it?
4. Is the reference a real Sitecore field? The publishing connector can't infer relationships that only exist in application code, an integrated GraphQL query or a custom content resolver.
5. Do the publishing logs show the dependent item being added to the pipeline? Temporarily enable debug logging to find out.
6. Is it even Edge? Query Edge directly for both the referenced item and the dependent page's layout. If Edge has the new value, you're looking at ISR or some other front end cache.

A direct TreeList reference looks like something Experience Edge should just understand. It can, but you have to ask it to.

Then republish so Edge catches up.

• Publishing optimization, Sitecore Accelerate
• Publishing to Experience Edge, SitecoreAI documentation
• Publishing to Experience Edge, Sitecore Accelerate

Stay dependable,

-MG