Sitecore обеспечивает доступ к дочернему узлу вокруг родительского

Убедитесь, что вы установили атрибуты hostName и targetHostName в вашей <site> конфигурации. Это гарантирует, что при переходе по ссылке на контент между сайтами ссылка будет отображать полный URL-адрес, включая имя хоста.

hostName: The host name of the incoming url. May include wildcards (ex. www.site.net, *.site.net, *.net, pda.*, print.*.net)
          It's possible to set more than one mask by using '|' symbol as a separator (ex. pda.*|print.*.net)
targetHostName: The host name to use when generating URLs to items within this site from the context of another site.
          If the targetHostName attribute is absent, Sitecore uses the value of the hostName attribute instead.
          Used only when the value of the Rendering.SiteResolving setting is true.

И убедитесь, что Rendering.SiteResolving=true

  <!--  SITE RESOLVING
        While rendering item links, some items may belong to different site. Setting this to true
        make LinkManager try to resolve target site in order to use the right host name.
        Default value: true
  -->
  <setting name="Rendering.SiteResolving" value="true" />

Вы всегда сможете получить доступ к странице с полным путем, поэтому, как говорит Йенс, добавьте канонические теги ссылок. После того, как вы решите проблему с межсайтовыми ссылками и каноническими ссылками, роботы Google должны только переходить по чистым ссылкам.

Похоже, вы пропустили атрибут имени хоста в конфигурации вашего узла «веб-сайт». Если у вас есть 2 веб-сайта, вам также понадобятся 2 узла веб-сайтов с соответствующим именем хоста.

Вы не используете в конвейерах никакой настраиваемый преобразователь элементов? Это тоже могло вызвать это

Sitecore имеет ряд проблем с созданием многосайтовых ссылок, некоторые из которых были устранены в последней версии 6.6: http://sdn.sitecore.net/Products/Sitecore%20V5/Sitecore%20CMS%206/ReleaseNotes/ChangeLog/Release%20History%20SC66.aspx#660update6 (см. Раздел об изменениях в поставщике ссылок).

Также достаточно просто добавить несколько дополнительных средств защиты от шума между площадками, подобного этому. Вы можете добавить шаг после ItemResolver в конвейере httpRequestBegin примерно так (извините, немного не хватает времени, чтобы написать компилируемый пример, это должно дать идею):

Item siteRoot = Sitecore.Context.Site.StartItem;
if (!(Sitecore.Context.Item.ID == siteRoot.ID || Sitecore.Context.Item.Axes.IsDescendantOf(siteRoot))
  // break and do 404

Способ, которым Sitecore разрешает элементы, позволяет получить доступ к страницам на нескольких сайтах и ​​с несколькими доменами.

Если у вас следующая структура:

-sitecore
--content
--- site1
---- site1page1
--- site2
---- site2page1

И site1 имеет домен site1.com, а site2 имеет site2.com, вы всегда можете адресовать элемент с его полным путем. Так, например, вы можете получить доступ к страницам site2 на site1 следующим образом:

site1.com/sitecore/content/site2/site2page1.aspx

Есть несколько способов справиться с этим в отношении SEO, но самый простой - использовать канонические ссылки в метаданных, чтобы Google не рассматривал это как дублированный контент. Затем вы можете добавить логику для отображения метатега с нужным URL-адресом на всех страницах.

Если вы не хотите, чтобы страницы с одного сайта отображались на другом сайте, вам следует создать разные домены для каждого сайта, а затем использовать безопасность Sitecore, чтобы запретить доступ для чтения с одного сайта на другой. Например, вы можете создать site1 как домен, а затем ограничить доступ для чтения к элементам site2 в этом домене.

Я согласен с тем, что стандартный ItemResolver слишком снисходителен к URL-адресам. Вы можете не только получить одну и ту же страницу на любом сайте, но и получить дубликаты, используя полный путь Sitecore (например, / sitecore / content / Site / page). В одном проекте, где это было большой проблемой для клиента, я создал настраиваемый ItemResolver, который был бы более строгим. Вот:

public class ItemResolver : Sitecore.Pipelines.HttpRequest.ItemResolver
{
    public override void Process(HttpRequestArgs args)
    {
        Assert.ArgumentNotNull(args, "args");
        if (((Context.Item == null) && (Context.Database != null)) && (args.Url.ItemPath.Length != 0))
        {
            if (Context.Domain.Name.ToLower() == "sitecore")
            {
                base.Process(args);
                return;
            }

            Profiler.StartOperation("Resolve current item.");
            string path = MainUtil.DecodeName(args.Url.ItemPath);
            Item item = args.GetItem(path);
            if (item != null)
            {
                Tracer.Info("Current item is \"" + path + "\".");
            }
            Context.Item = item;
            Profiler.EndOperation();
        }
    }
}

Если вы сравните его с декомпилированным стандартным ItemResolver, вы увидите, что это тот же код, который использовался для первого шага. Он просто не пытается найти предмет другими способами, если этот первый шаг не удается. Еще одно приятное преимущество этого заключается в том, что он работает немного быстрее, чем стандартный ItemResolver.