Sitecore Experience Accelerator (SXA) FAQs

Current version: 1.8

Find the answers to commonly asked questions on SXA installations.

Can you mix SXA and non-SXA websites within a single Sitecore instance?

Yes (and no). The challenges of mixing SXA with other solutions are the same as with running any two solutions from different implementers on a single Sitecore instance. Non-SXA sites and SXA sites share pipelines, and both attempt to add processors and modify Sitecore behavior to its needs.

SXA did extensive reviews of all pipelines within recent releases. We have made sure we abort our processors whenever we detect that they are running outside of the context of SXA sites, for the very purpose of limiting any interference that SXA could cause for another solution.

We have tested it working with the Habitat and confirmed that they could run side by side. SXA should be as unobtrusive as any Sitecore solution can be to another solution.

On the other hand, SXA is not in control of the behavior of the processors from the other solution - which means the cohabiting code also needs to be a good neighbor and check for interference with SXA’s operation if it is to be deployed to the instance that co-hosts SXA.


Integration due diligence QA is always necessary when there are two solutions running in a single process.

Can you host a non-SXA site within an SXA tenant?

Yes. A non-SXA site does not participate in a tenant's operations, but it should not cause problems either. For SXA, a tenant is mostly a container for templates and the grouping under /sitecore/Content is only reflecting that. It is the site that is a unit of execution.

Can SXA pages contain non-SXA components?

Yes. SXA pages can contain both SXA and non-SXA components. You can include these components in sitecore/Content/<Tenant>/<Site>/Presentation/Available renderings. The components can be placed on the page and will function as long as they are not making assumptions as to the site structure that is conflicting with SXA. If this happens, you can usually mitigate this fairly easily.

You can choose to create an SXA rendering of your component. If you choose not to convert the component into SXA components, the component will not be able to:

  • Use SXA styles. Styling these components can be more difficult.

  • Use SXA grid settings. Resizing these components can be more difficult.

  • Participate in the Creative Exchange styling process.

Can I use SXA components outside of an SXA site?

No. SXA components do not function outside of SXA sites. Because SXA components make many assumptions about, for example, the site structure, the data sources, this possibility is disabled.

Is there a limit on the number of sites that you can have in a single SXA installation?

No. SXA has no inherent limit other than those of the platform itself. SXA is as scalable as the Sitecore environment to which you deploy it. Please consult the general platform architecture recommendations with your partner.

Is the Sitecore PowerShell Extensions (SPE) required to be installed on every instance in the environment?

No. SPE module is only used or required for certain Content Management tasks, and you should not deploy it on Content Delivery servers.

Where can I download the SPE WDP files required for Azure deployment?

There is a matching SPE WDP file on the download page in the Azure section for every SXA release.


Sitecore includes Sitecore PowerShell Extensions (SPE) on the download page as a convenience for deployment purposes. However, the SPE is a third-party module that is not officially covered by the Sitecore Support services. Sitecore supports the scenarios covered in the scripts that come with SXA out of the box. This means that Sitecore does not provide support for scripts that come with SPE or any third party scripts. Sitecore does not issue fixes for or support any usage of the module outside of the scope of the standard scripts.

What is Sitecore doing to prevent components from breaking between versions?

  • Most of the components are rendered using Rendering Variants that are defined as Sitecore items and are in full control of the client/developers.

  • The JavaScript that provides functionality for a component exists in a Base theme that is under SXA’s control. Extracting the JavaScript from the site theme means that when we find a problem or need to provide additional functionality, Sitecore can do it without interfering with the client theme.

  • The markup of components does not change often.

  • SXA 1.8 introduced the ability to replace markup for existing components, which means that even if we changed it in a future version, you could revert it to the old markup if needed.

  • When SXA introduces a big change to a component, it is marking the old component as obsolete (and does not deploy it to sites that you create after the upgrade). Your existing sites can keep using the old version.

  • When the data structures for components change (data source or rendering parameters), we provide migration scripts that perform the transformation to a new structure.


You must always verify that your website looks and feels consistent with how it worked before the upgrade. Themes are considered customization and Sitecore does not modify your themes to comply with any possible changes introduced to the markup.

Do you have some feedback for us?

If you have suggestions for improving this article,