Here the Sitecore documentation says:

In multisite environments where you only want to enable language fallback on a subset of the websites, you need to create a specific shell site for each website where you want the language fallback feature enabled.

What should be the configuration for the the specific shell site?

  • doc.sitecore.net/sitecore_experience_platform/… Enable site-level language fallback section Commented Jul 5, 2017 at 9:20
  • yes, I found this exactly, just the quoted text makes me confused, how should it be configured. Commented Jul 5, 2017 at 9:27
  • I enabled language fallback few times and I never created any site specific shell sites. shell can be only one. For me this You must enable the attributes on the shell and on each of the relevant websites. says everything. I might be wrong but I think that quoted part of the docs is incorrect. Commented Jul 5, 2017 at 9:45
  • 3
    It is not. Partial answer here: sitecore.stackexchange.com/questions/5873/…
    – Mark Cassidy
    Commented Jul 5, 2017 at 9:56
  • Thanks. That make sense but like you said doing this may not ;) Commented Jul 5, 2017 at 10:27

1 Answer 1


In short; I probably wouldn't do it.


The issue here is; that Language Fallback is a mechanism that not only affects your content delivery; it also affects behaviour inside the Sitecore clients themselves (Experience Editor and Content Editor).

These both run in the context of the "shell" site.

For a solution wide approach, see the answer already given here: What is the use of "shell" website in the Sitecore.LanguageFallback.config file

The issue is; once you enable Language Fallback for "shell", it will take effect on Experience Editor and Content Editor - regardless of what site you are actually editing. There is no way around this; this is just how these Sitecore client interfaces work.

What it means

So essentially; if you want different behaviour by-site, you are going to have to configure separate Content Editing (Sitecore Client) environments per site. The way to do this, would be to configure additional "shell" sites.

It's easy enough to do, as such. At least on paper. You can define multiple sites inheriting from your "shell" site (as shown in the linked answer), and additionally configure them with a hostName attribute to respond to. The end result being; you go to www.site1.com/sitecore, the "shell" site without Language Fallback gets triggered. And then www.site2.com/sitecore with Language Fallback enabled.

But your editors would need to log in and out using different host names, and I don't really think they're going to appreciate this.

  • Another approach could be to split the templates. Let's say we have a Fallback News template and Not Fallback News. It's a workaround but a possible solution. What do you think? Commented Jul 5, 2017 at 19:17
  • That could be, but wasn't your question though ;-)
    – Mark Cassidy
    Commented Jul 5, 2017 at 19:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.