none
Search returns incorrect document title under SharePoint 2013

    Question

  • I found a number of questions about this issue. For exampe "Search Results not showing document title" http://social.technet.microsoft.com/Forums/zh/sharepointsearch/thread/40fb2b1a-58c5-4ae2-aada-56d15adc9e00 but no answer worked for me.

    If I perform a search query programmatically I do not get the right document title - how can I prevent the search under SharePoint 2013 to take for example the first line of word documents instead of the title column of the document library or the Metadate of the document itself? Is there a "EnableOptimisticTitleOverride" Key like under SharePoint 2010 to change the behaviour under 2013?

    Monday, February 11, 2013 12:46 PM

Answers

  • There are approximately 10 crawled properties mapped to the Title managed property, with the option to use the first non-empty crawled property as the value based on the order in the mapping list. You may want to change the order of the crawled property mappings to the crawled property you want. The problem is that what each crawled property represents is undocumented, so it becomes trial and error. Hope this helps.

    Blog | SharePoint Field Notes Dev Tool | ClassMaster

    Wednesday, February 13, 2013 3:55 AM

All replies

  • Hi PhSe, 

    just to highlight my findings that were described in the post that you mentioned:

    No, it doesnt seems to be feasible in this version, other that trying to fool the classifier, which is not practical. Does it happen with ALL your documents?

    Metadata(including title) extraction is a part of flow described in Bundle.xml resource of Microsoft.MetadataExtractorSubFlow.dll. Theoretically it is possible to modify the XML and exlclude this step, but you will not be able to sign the assembly to match the original reference.

    Monday, February 11, 2013 2:45 PM
  • Thanks a lot.

    Cannot understand why the first line of the document is higher ranked as the title.

    No it happens not to all documents but to a lot. Why?

    Monday, February 11, 2013 5:32 PM
  • Metadata extraction uses "machine learning" magic to determine whether a line of text in header of document is a title. This magical recipe include different ingredients such as style of font(size, color, bold, alignment), position, presence\ absence of specific pre-defined words etc.

    My guess is that in some cases the mixture of these ingredients produces something wrong:) If you can share some documents I could try to troubleshoot, fortunately(unfortunately?) I dont have this issue in my environment\documents.

    Monday, February 11, 2013 6:28 PM
  • There are approximately 10 crawled properties mapped to the Title managed property, with the option to use the first non-empty crawled property as the value based on the order in the mapping list. You may want to change the order of the crawled property mappings to the crawled property you want. The problem is that what each crawled property represents is undocumented, so it becomes trial and error. Hope this helps.

    Blog | SharePoint Field Notes Dev Tool | ClassMaster

    Wednesday, February 13, 2013 3:55 AM
  • I still see no resolution to this issue or an answer from anyone in Microsoft as to whether this it is possible or not to replicate the behaviour of EnableOptimisticTitleOverride in SharePoint 2013.

    I have tried all sorts of changes to the Title Crawled Properties in the Search Schema, but it makes no difference at all.

    Just to some up my issue, is that it is using the first line of several documents, even though the Title is clearly set in SharePoint.  In this scenario the worst thing it can do is pick the first line of the document for the title. 

    I am getting really frustrated that I cannot simply turn this off.

    Wednesday, June 26, 2013 11:22 AM
  • I have a case in to Microsoft concerning this same issue. When I receive a resolution, I will post it
    Thursday, June 27, 2013 2:05 PM
  • Did the post marked as the answer actually work for anyone?  If so, can you share what the crawled property mapping order is?
    Wednesday, July 3, 2013 4:27 PM
  • Hi,

    The issue is caused by MetadataExtractor that works for Word and PowerPoint documents. Actually it finds a candidate title in the document body and overrides ALL the crawled titles coming from SharePoint, Office, etc. This causes the described situation when mapping change doesn't help to resolve the issue.

    EnableOptimisticTitleOverride doesn't work in SP2013. But there exist a workaround (only for SP2013, will not work for SP2010)

    1. Create a new managed property in the tenant admin, let's say OriginalTitle. To be more specific, you cannot create a new managed property but can rather use an already existing empty managed property of Text type. For example, this can be Title1 managed property or any other that is not currently used
    2. Set up the mapping from the crawled Title property to this new managed property. Since the title from SharePoint is added as a crawled property, then mapped to managed properties by AttributeMapper and only after that is overwritten by MetadataExtractor, OriginalTitle will keep the title you want.
    3. Create a display template for every document type so that the OriginalTitle is displayed on the search page instead of the Title (which now containes title from MetadataExtractor and you want to omit). The detailed instruction can be found at http://msdn.microsoft.com/en-us/library/jj945138.aspx

    We are currently working on the fix at the moment. The fix will be included in the October cumulative update and SharePoint customers will receive it even earlier.

    Best,

    Ievgeniia

    • Proposed as answer by RoyJoyson Tuesday, July 16, 2013 3:05 AM
    Thursday, July 11, 2013 1:05 PM
  • One of the problems with the solution above is it won't fix the "_layouts/15/osssearchresults.aspx" search results page.  Will the October Cumulative update resolve that issue as well? 

    Thanks. 

    Nick Hurst

    Monday, July 15, 2013 7:19 PM
  • Hello Ievgeniia, 

    You say "SharePoint customers will receive it even earlier" how do we get are hands on it. My client is running 2013.

    Thanks


    Eric

    Thursday, September 12, 2013 2:10 AM
  • HI Ievgeniia,

    I'am also looking for a solution for this problem and we already have SharePoint 2013 running. Could yo inform me how to get the fix as early as possible or maybe only the KB fixing this problem.


    Maik

    Wednesday, September 18, 2013 10:00 AM
  • None of the solutions in this thread are feasible. I hope the SharePoint team realize the seriousness of this issue. We cannot use search for solution building until this is resolved. And have actually had to re-architect solutions because of this. So this problem has cost us money.

    Can anyone from Microsoft give us a date this will be fixed?

    Wednesday, October 9, 2013 6:32 PM
  • So I just looked through the October CU and I don't see anything mentioned about fixing this.  Has anyone installed the October CU yet?  Any ideas if this actually got fixed or not? 

    Nick Hurst

    Wednesday, October 30, 2013 9:35 PM
  • Hi Nick,

    You are right. This problem isn't fixed in the october CU. At the moment we are in contact with microsoft support and they are telling us it will be in the december CU.

    I really have my doubts.


    Maik

    Friday, November 8, 2013 4:03 PM
  • As usual for Microsoft, the right hand has no idea what the left hand is doing.  So I stumbled across a MSDN blog called SharePoint Escalation Services Team Blog.  And according to this blog post, the ability to remove what was known as Optimistic Titles in 2010, now known as MetadataExtractorTitle in 2013, can be removed after the October Cumulative update:
    http://blogs.msdn.com/b/spses/archive/2013/10/31/show-more-relevant-titles-in-search-results-in-sharepoint-2013-plus-some-other-improvements.aspx

    Unfortunately we haven't had a chance to install the Oct CU and test this yet, so I'm not sure what to believe at this point.  Hopefully we can get this installed early next week and I'll post my findings here.


    Nick Hurst

    Friday, November 8, 2013 4:21 PM
  • So we installed the October CU, and it made the MetadataExtractorTitle crawled property visible in the #1 position on the 'Title' Managed Property.  We tried moving the MetadataExtractorTitle down in order and doing a Full Crawl, but the MetadataExtractorTitle was still being displayed in search results.  So we tried removing the MetadataExtractorTitle property, and then doing a Full Crawl, again no change in search results. 

    We tried to Reindex a document library and upload new powerpoint and word documents to see if the SharePoint title or document name would be displayed on new content at least, but that didn't work either.  Finally out of frustration, we did an Index Reset which erases the content index, and then did a Full Crawl to repopulate it.

    That actually worked!  So now the SharePoint Title is being displayed for Word and PowerPoint documents, and if there is no Title, the document name is being displayed.  This is working on both the Enterprise search center and on the site specific "_layouts/15/osssearchresults.aspx" search results page. 

    The problem is, we would like to avoid doing an Index Reset on production if at all possible.  I'm concerned that we might lose some the page views (Most Popular), individual search suggestions and some of the relevancy of the search results if we do this.  I posted a follow up question on the Escalation Blog to see if the search team has any other recomendations:
    http://blogs.msdn.com/b/spses/archive/2013/10/31/show-more-relevant-titles-in-search-results-in-sharepoint-2013-plus-some-other-improvements.aspx

    My one thought is perhaps one of the nightly timer jobs would have updated the search results.  We are going to take a look at restoring our Dev environment to an earlier snapshot and then re-installing the Oct CU and try this again to see if making the MetadataExtractorTitle changes and then leaving it overnight will somehow re-index the Title managed property. 

    Thanks.


    Nick Hurst

    Thursday, November 21, 2013 3:48 PM
  • Nick,

    Did you get a chance to restore the Dev environment like you planned? We are in the same predicament basically. The Oct. CU alone does not resolve this issue for our 2013 environment.

    Monday, December 2, 2013 7:41 PM
  • Unfortunately we haven't gotten back to it yet. 
     
    Just to confirm, you installed the Oct. CU, removed the 'MetadataExtractorTitle' crawled property from the 'Title' Managed property, and then did a full crawl? 
     
    Thanks. 


    Nick Hurst

    Monday, December 2, 2013 7:52 PM
  • Is there not an option to do the same with MetaDataExtractorTitle on SharePoint Foundation 2013?  As at the moment it is reading the footer page number in some documents, which is making it completely useless.
    Monday, January 27, 2014 9:14 AM
  • I've posted a couple questions on the SharePoint Escalation Services Team Blog trying to confirm that a Index Reset was required, with no response.  We ended up having to do an Index Reset for both our QA and Production environments in order to get the MetaDataExtractorTitle to stop displaying in the search results.  Maybe there is another way, but we tried several Full Crawls on both environments and that didn't do anything.  

    Index Reset on Production is not a great solution, since it appears many libraries lose the # of views for pages and documents when you do it. 

    Unfortunately the documentation for any of this is either incredibly poor, non-existent, or hidden so well that no one can find it.

    TimCollins10c:  Sorry I'm not that familiar with SharePoint Foundation, are you missing the 'Search Schema' option in Central Admin?   


    Nick Hurst

    Wednesday, January 29, 2014 12:58 AM
  • In Foundation you can still get most of the same basic search pages e.g. Search Schema

    So on the Server version I did not have any trouble finding the new crawled property and removing it.  Although like you I agree it is a painful process when you don't have any good documentation on the fix.

    On Foundation the property does not appear after the equivalent CU's being applied and same process being followed.

    This issue has caused us to have to add an alternative Title Meta value and use that in all the locations we can, as a temporary workaround.  Very annoying to have to create a work around for the most basic of functionality as a Title.

    Wednesday, January 29, 2014 8:56 AM
  • We were able to successfully retrieve the document title after a two phase configuration change.

    First, apply the October CU for SP2013.

    Secondly, change the configuration of the "Title" managed property so that the "Office:2" property is the highest ranking, even higher ranking than the "MetadataExtractorTitle" property. Then full crawl...

    Hope this helps.

    • Proposed as answer by Cory Syvenky Wednesday, February 5, 2014 10:15 PM
    Wednesday, February 5, 2014 10:15 PM
  • It seems that the solution of the issue with Document Titles in Search results is correct with :
    - SP2013 Cumulative update of October 2013 
    - An additional configuration explained here : http://consultant.tamjid.com/425/fixed-search-results-not-showing-document-titles/   (or also in this article comments, by putting the "Office:2" property at the top of the mapping for "Title" in the Global Search Schema)


    But if you work with a SharePoint 2013 without the cumulative update, I found a solution to display the real "Title" property value instead of the first line of document body in SharePoint 2013 search results : 

    1. Navigate to target Site Collection > Search Settings > Search Schema

    2. Select a RefinableString (for example, RefinableString01)

    3. Add a mapping with the crawled property "Office:2" (it contains the Title value)

    4. Edit the search display template (either the standard one, or your custom display template) with the two instructions below.

        - Add the name of your RefinableString in the <mso:ManagedPropertyMapping msdt:dt="string"> tag
                  =>    <mso:ManagedPropertyMapping msdt:dt="string">'RefinableString01':'RefinableString01',...........
      
       - Display the Title in your display template by adding this tag :
               =>   _#= ctx.CurrentItem.RefinableString01 =#_

    5. Navigate to "Site Settings > Search Result Types", and click "Update" in the yellow ribbon asking to update the latest properties.

    6. Perform a full crawl (maybe an incremental is enough, but I did not check)

    7. Et voilà ! Tout fonctionne ! The real title is displayed in the search results instead of the first lines of the document body.
    Thursday, August 28, 2014 3:17 PM
  • Hello,

    I have exactly the same problem : document titles are incorrect in search result.

    I tried to apply the solution proposed by Florian frenchy, but with no result .. i must be doing something wrong, but what ?

    i did with no problem part 1 to 4 : select refinableSting01 and add a mapping with Office:2.

    But from the 4th point, problems started :

    • I managed to create a new display tempate named and modified it like Florian explained : i added the name of refinableString01 in the mso:managedPropertyMapping. I added it in replacement of the Title property, wich doesn't appear anywhere in my code now.
    • but where should i add the tag  _#= ctx.currentitem.RefinableString01 =#_  ? I tried in the body (cf screen capture below), but i still have my wrong title's problem .... I think i didn't add this tag at the right place, but could you precise me exactly where to add it ?

    i have of course perform a full crawl.

    i join here the code of the html doc :

    <html xmlns:mso="urn:schemas-microsoft-com:office:office" xmlns:msdt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882">
    <head>
    <title>Élément Word</title>

    <!--[if gte mso 9]><xml>
    <mso:CustomDocumentProperties>
    <mso:TemplateHidden msdt:dt="string">0</mso:TemplateHidden>
    <mso:MasterPageDescription msdt:dt="string">Affiche un résultat adapté pour un document Microsoft Word.</mso:MasterPageDescription>
    <mso:ContentTypeId msdt:dt="string">0x0101002039C03B61C64EC4A04F5361F385106603</mso:ContentTypeId>
    <mso:TargetControlType msdt:dt="string">;#SearchResults;#</mso:TargetControlType>
    <mso:HtmlDesignAssociated msdt:dt="string">1</mso:HtmlDesignAssociated>
    <mso:ManagedPropertyMapping msdt:dt="string">&#39;RefinableString01&#39;:&#39;RefinableString01&#39;,&#39;Path&#39;:&#39;Path&#39;,&#39;Description&#39;:&#39;Description&#39;,&#39;EditorOWSUSER&#39;:&#39;EditorOWSUSER&#39;,&#39;LastModifiedTime&#39;:&#39;LastModifiedTime&#39;,&#39;CollapsingStatus&#39;:&#39;CollapsingStatus&#39;,&#39;DocId&#39;:&#39;DocId&#39;,&#39;HitHighlightedSummary&#39;:&#39;HitHighlightedSummary&#39;,&#39;HitHighlightedProperties&#39;:&#39;HitHighlightedProperties&#39;,&#39;FileExtension&#39;:&#39;FileExtension&#39;,&#39;ViewsLifeTime&#39;:&#39;ViewsLifeTime&#39;,&#39;ParentLink&#39;:&#39;ParentLink&#39;,&#39;FileType&#39;:&#39;FileType&#39;,&#39;IsContainer&#39;:&#39;IsContainer&#39;,&#39;SecondaryFileExtension&#39;:&#39;SecondaryFileExtension&#39;,&#39;DisplayAuthor&#39;:&#39;DisplayAuthor&#39;,&#39;ServerRedirectedURL&#39;:&#39;ServerRedirectedURL&#39;,&#39;SectionNames&#39;:&#39;SectionNames&#39;,&#39;SectionIndexes&#39;:&#39;SectionIndexes&#39;,&#39;ServerRedirectedEmbedURL&#39;:&#39;ServerRedirectedEmbedURL&#39;,&#39;ServerRedirectedPreviewURL&#39;:&#39;ServerRedirectedPreviewURL&#39;</mso:ManagedPropertyMapping>
    <mso:_dlc_DocId msdt:dt="string">5J743RRRX2JJ-1-226</mso:_dlc_DocId>
    <mso:_dlc_DocIdItemGuid msdt:dt="string">bd169460-a149-4860-88f8-24f1f21e4f94</mso:_dlc_DocIdItemGuid>
    <mso:_dlc_DocIdUrl msdt:dt="string">http://hvsvbclsp/sites/ged/_layouts/15/DocIdRedir.aspx?ID=5J743RRRX2JJ-1-226, 5J743RRRX2JJ-1-226</mso:_dlc_DocIdUrl>
    <mso:HtmlDesignConversionSucceeded msdt:dt="string">True</mso:HtmlDesignConversionSucceeded>
    <mso:HtmlDesignStatusAndPreview msdt:dt="string">http://hvsvbclsp/sites/ged/_catalogs/masterpage/Display Templates/Search/Item_Word.html, La conversion a réussi.</mso:HtmlDesignStatusAndPreview>
    <mso:CrawlerXSLFile msdt:dt="string"></mso:CrawlerXSLFile>
    <mso:HtmlDesignPreviewUrl msdt:dt="string"></mso:HtmlDesignPreviewUrl>
    </mso:CustomDocumentProperties>
    </xml><![endif]-->
    </head>

    <body>
        <div id="Item_Word">
    <!--#_
            if(!$isNull(ctx.CurrentItem) && !$isNull(ctx.ClientControl)){
                var id = ctx.ClientControl.get_nextUniqueId();
                var itemId = id + Srch.U.Ids.item;
       var hoverId = id + Srch.U.Ids.hover;
                var hoverUrl = "~sitecollection/_catalogs/masterpage/Display Templates/Search/Item_Word_HoverPanel.js";
       $setResultItem(itemId, ctx.CurrentItem);
                ctx.CurrentItem.csr_Icon = Srch.U.getIconUrlByFileExtension(ctx.CurrentItem);
                ctx.CurrentItem.csr_OpenApp = "word";
                ctx.currentItem_ShowHoverPanelCallback = Srch.U.getShowHoverPanelCallback(itemId, hoverId, hoverUrl);
                ctx.currentItem_HideHoverPanelCallback = Srch.U.getHideHoverPanelCallback();
    _#-->
                <div id="_#= $htmlEncode(itemId) =#_" name="Item" data-displaytemplate="WordItem" class="ms-srch-item" onmouseover="_#= ctx.currentItem_ShowHoverPanelCallback =#_" onmouseout="_#= ctx.currentItem_HideHoverPanelCallback =#_">
        _#=ctx.RenderBody(ctx)=#_
        _#= ctx.CurrentItem.RefinableString01 =#_
                    <div id="_#= $htmlEncode(hoverId) =#_" class="ms-srch-hover-outerContainer"></div>
                </div>
    <!--#_
            }
    _#-->
        </div>
    </body>
    </html>

    And in my search result, i still have my wrong title's problem. ex : a word doc appears with this title : "Recette Cluster ARF C.H. Valence". It's title in the properties of the doc is "Recette Cluster ARF".......

    thank's for what you'll be abble to do to help me ....

    Have a nice day,

    Stephanie

    Monday, November 23, 2015 12:50 PM
  • Just want to add some additional information on this query. You can refer below articles which give more information about mapping and solution:-

    https://joannecklein.com/2017/02/12/demystifying-titles-in-sharepoint-search-delve/

    https://platinumdogs.me/2016/04/07/sharepoint-search-and-the-inconvenient-metadataextractortitle-crawled-property/

    Thanks

    -Samit


    Samit Pathak

    Monday, January 14, 2019 11:21 PM