The publishing process

Publishing to Experience Edge starts when you trigger a publishing operation in SitecoreAI. After you start the publishing operation, Sitecore automatically handles the process, which includes creating a schema and publishing it to Edge. The Sitecore publishing pipeline identifies the items to publish, and uses them to create the initial publishing manifest.

Note

The schema is created automatically, taking into account the publishing restrictions of the items, and can't be changed.

Only items under the following paths are included in the manifest:

  • /sitecore/content

  • /sitecore/media library

  • /sitecore/templates

  • sitecore/system/dictionary

If you publish a site, it might include other items from any path due to their relations to the content being published. Make sure that you protect sensitive items from accidentally being published using publishing restrictions.

Logging

Before you publish, you can set up a verbose logging process for troubleshooting, to understand which items were published and why. You can specify the level of logging by using an environment variable: PUBLISHING_LOG_LEVEL_VALUE.

To enable logging for every item version that is published, create a patch file that uses the traceToLog setting in the Sitecore.ExperienceEdge.Connector.Client.Pipelines.EdgePublishItem.UpdateStatistics processor of the edgePublishItem pipeline. When publishing to Edge, not all published item versions appear in these logs.

RequestResponse
	<edgePublishItem patch:source="ExperienceEdgeConnector.config">
                  ...
                  <processor type="Sitecore.ExperienceEdge.Connector.Client.Pipelines.EdgePublishItem.UpdateStatistics,  Sitecore.ExperienceEdge.Connector.Client" method="Process" resolve="true">
                    <traceToLog>false</traceToLog>
                  </processor>
		</edgePublishItem>

When traceToLog is set to true, publishing information is logged and available in the log file. You can access the log file in the Deploy app.

An example log record:

RequestResponse
6584 11:19:00 INFO  ##Publish Item: Name=A content item, Uri=sitecore://master/{EF687BD4-3C0D-4121-8B63-C7B602DF3213}?lang=fr-FR&ver=1, Operation=Updated, ChildAction=Skip, Explanation=Version 'fr-FR_1' was published.

These are the available log details:

  • Operation - the publish action taken on a publishing candidate (target item). Possible values are skip, update, create, or delete.

  • ChildAction - the publish action taken on child items. Possible values are skip, allow, or force.

  • Explanation - a description of the publishing status, such as whether an item was published and some details.

Publishing to Experience Edge

The communication with Experience Edge happens through the delivery Remote Procedure Call (RPC) endpoint. All calls to the endpoint are secured and authorized using bearer tokens. The module creates and refreshes the tokens automatically.

When publishing starts, Sitecore runs the publishing process as follows:

  1. The JobStart event is published to Experience Edge.

  2. The Sitecore GraphQL Schema is generated and the schema entity is published to Experience Edge.

  3. Edge is called to compare the items to be published with the ones that already exist.

  4. If the publish job is smart or incremental, each item in the queue is reviewed to calculate all the dependent items that need to be published:

    • Rendering data source - if the initial manifest contains an item that is used as a rendering data source by some page, and the publishing mode is snapshot publishing (v1), that page is added to the queue.

    • Template - if the initial queue contains a template item, all items based on that template (directly or through inheritance) are added to the queue. The newly added items are also checked for page dependencies.

    • Template field - if the initial queue contains template fields, the owner template is expanded the same way a template is.

    • Language fallback - language fallback is reviewed for all queue items, and if the queue contains a version for a source language, the versions for fallback language(s) are automatically added to the queue. This feature is disabled by default on Edge, and you can enable it if needed.

    • The root item of the content site - if the initial queue contains the root item of the content site, the site information is automatically included in the queue and available on Edge as the SiteInfo entity.

  5. All items, templates, and template fields in the queue are mapped to static format entities specific to Experience Edge and published.

    • If the queue contains pages (items with layout), the layout data is calculated and published to Experience Edge.

    • Media blobs are uploaded to Experience Edge.

    • Media metadata is mapped to static format entities specific to Experience Edge and published.

  6. The JobEnd event is published to Experience Edge.

Note

When you use Experience Edge for the first time, perform a full site republish.

Processing entities on Experience Edge

After all the published entities have been uploaded to Experience Edge, Sitecore runs the following additional operations to finalize the publishing:

  1. Edge publishing – various actions run in Edge to finalize publishing.

  2. Edge cache clear – all caches are cleared to ensure the newly published content becomes available for consumption.

  3. Edge webhooks – in case there are any webhooks configured, they are triggered at the very end of the publish operation to ensure that downstream systems can access the newly published content.

After the publishing job is complete, Sitecore waits an additional 30 seconds to make sure there are no more publish operations, then clears the cache for the Edge tenant, and finishes processing JobEnd messages. It can take up to one minute for the cache to be fully purged, so a complete cache refresh finishes in 30-90 seconds.

Using PowerShell scripts to trigger publish operations

You can create PowerShell scripts to trigger publish operations using the Sitecore PowerShell Extensions Module. SitecoreAI does not define a fixed maximum number of items that can be processed in a single PowerShell operation. Depending on the content size, number of languages and versions, custom pipelines, and the available memory, there is a risk of a System.OutOfMemoryException error.

To prevent memory exhaustion and service instability, follow these guidelines:

  • Always process large create, update, or publish operations in small batches. A practical starting point is 200–500 items per batch for heavy operations.

  • Avoid scripts that load or loop through the entire content tree or store very large item lists in memory.

  • Do not store large item collections in variables; process items as a stream and release references between batches.

  • Schedule heavy PowerShell jobs outside business hours and avoid running them alongside other resource-intensive tasks.

  • Always test at small scale first in a non-production environment and increase batch sizes gradually while monitoring memory usage.

  • Split long-running jobs into multiple executions instead of running a single prolonged script.

Large unbounded PowerShell operations are not supported in SitecoreAI and may lead to service restarts or temporary outages.

Publishing results and potential failures

The publishing job may report failed entities during publishing to Experience Edge. These failures are often entity-level and do not always indicate that a content item failed to publish. Publishing can complete successfully even when failed entities are reported.

For a detailed explanation of common publishing failure scenarios and how to assess their impact, see Publishing failures and diagnostics.

Do you have some feedback for us?

If you have suggestions for improving this article,