Crawler results in SPSE Onprem

Robertsson, Kjell 20 Reputation points
2026-09-16T12:37:03.4333333+00:00

Hello

I have a spse onprem. One WebApp have two zones, Default and Internal. Both have ADFS/Win Auth, Default on port 443, and Internal on 8443.

I have set the Content Sources for Crawler to https://sp-tst-internal.domain.local. Multiple Content Sources, and crawl works fine everywhere. I also have setup Server Name Mappings correctly.

Now, if a user makes a search the right url shows up in 80% of the cases, but 20% points towards Internal zone. I have done a Index reset multiple times, both for the entire farm and on individual Site Collections.

Is there a solution to this matter? Some "Super-Reset" or similar?

Kind Regards
Kjell (As in seashell)

Microsoft 365 and Office | SharePoint Server | Development
0 comments
Answer accepted by question author
Michelle Nguyen 1,755 Reputation points Independent Advisor
2026-09-16T13:35:29.8+00:00

Hi @Robertsson, Kjell

Based on my research, the crawler can crawl the Default zone of the web application. Server Name Mapping does not remap all managed properties based on the URL in the index. Two specific properties explicitly noted as not being remapped are SPSiteUrl and ParentUrl.

Because different result rendering paths (standard results vs. contextual scoping vs. different content types vs. different templates) pull display URLs from different managed properties, some results are built from properties that your mapping successfully altered, while others are built from properties that the mapping never touched. It is very likely that 20% of the results are rendering from a managed property that structurally cannot be remapped, no matter how many times you crawl.

This also predicts something worth testing: contextual searches scoped to "this site" or "this list" are known to fail or return zero results under a similar configuration. If this is currently happening, it shares the exact same root cause.

An index reset even combined with a full re-crawl or a full farm reset, simply reapplies the same partial mapping behavior to the fresh data. It does not change which properties get remapped.

First, try pointing your content sources to the Default zone URL instead of the Internal zone, and drop the reliance on Server Name Mapping altogether. Since you mentioned both zones have both ADFS and Windows Auth available, check whether the crawl account can directly use the Default zone's Windows Auth provider (instead of ADFS). Zones in SharePoint can be configured with multiple authentication providers simultaneously, so you should be able to achieve the crawler-friendly NTLM/Kerberos path, which you initially set up the Internal zone for without actually needing to crawl a non-Default zone.

These are the insights I found, updating you so you're aware!

Was this answer helpful?

1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-09-16T12:37:19.0833333+00:00

    Yes. The likely cause is that the crawler is crawling the Internal non-default zone (https://sp-tst-internal.domain.local), so URL-related properties in the index are stored relative to that crawled zone. In SharePoint Server, when a non-default zone is crawled, the query processor does not remap result URLs to the zone from which the user is searching. That is why some results can surface with the Internal zone URL.

    A repeated index reset will not change that behavior. There is no supported “super-reset” that fixes it while continuing to crawl the non-default zone.

    The supported fix is:

    1. Change the crawl start address so the crawler uses the Default zone URL for that web application.
    2. Run a full crawl of that content source after changing it.
    3. Avoid crawling the same start addresses through multiple content sources in the same Search service application, because SharePoint does not support crawling the same start addresses by using multiple content sources.

    Why this happens:

    • If the default zone is crawled, SharePoint maps returned search-result URLs so they are relative to the AAM zone from which queries are performed.
    • If a non-default zone is crawled, search-result URLs remain relative to the non-default zone that was crawled.
    • URL-based properties in the index are then tied to that crawled non-default URL, which can also cause inconsistent refinements and unexpected result behavior.

    In the described setup, crawling https://sp-tst-internal.domain.local explains why some results point to the Internal zone. The corrective action is to crawl the Default zone URL instead, then full crawl so the index is rebuilt with the correct URL basis.

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.