Coveo for Sitecore - Endpoint Deprecation Issues? Upgrade the Coveo for Sitecore module

Even though we migrated Coveo endpoint to Organization specific endpoint, we still get email from Coveo that deprecated endpoints are being used. Looking at the traffic in Coveo administration, we were still getting much of the analytics traffic using deprecated endpoint. 

Coveo for Sitecore version: 5.0.1277.4 (Release date: October 23, 2023)

The latest Coveo for Sitecore module version (5.0.1368.1) has fixes for updating the analytics endpoint. In the release notes, we have quite a few Analytics related changes and proper analytics endpoints are being used with this version. 

WEB-6836: Fixed the content structure of the Coveo Page View Analytics request payload.

WEB-6922: Removed no longer required usage reporting.

WEB-6937: Fixed the analytics endpoint being used when you bypass the Coveo for Sitecore proxy.

WEB-6954: Simplified the way the Usage Analytics endpoint is composed, depending on the context.

Example: \Coveo\Hive\js\CoveoForSitecore.js

Once the module is upgraded, the traffic starts to drop in the deprecated endpoint and eventually leading to 100% in the recommended endpoint. 

Coveo for Sitecore - Clickable URI when content is outside of all Site definitions (Shared or Global Pages)

Coveo for Sitecore generated Clickable URI at the time of indexing, but the site part of the clickable URI is recomputed automatically at query time. What if the content is outside of site definition and how Coveo for Sitecore will resolve Site and generate the Clickable URI - this blog gives an overview of how it is handled in Coveo.

During the indexing time, Coveo for Sitecore will try to resolve the site definition so that URIs can be generated. In the site definition, hostname attribute can have multiple domains or wildcards. If it has multiple values, then targetHostName is mandatory so that Coveo can use it to generate the URIs. 

This is the order by which Coveo for Sitecore will try to resolve the site using ResolveItemSiteProcessor.

1. First, it will eliminate all non-content sites - coveo_website, coveoanalytics, coveorest, coveoapi, shell, login, admin, service, modules_shell, modules_website, scheduler, system, publisher. 
2. It will concatenate rootPath and startItem of each content site definition and compare it with the Item path.
3. If the language attribute is available in Site definition, then it will be compared with the item language. 
4. If no site is selected with the previous steps, then it will choose the first site of the remainder content site.
5. If no site is resolved, then it will use Sitecore Setting 'serverUrl' value if available. 
6. If no site is selected in any of the steps, then default host of the Sitecore installation will be used. 

In our case, we have Global and Stores content page items which are not part of any of the site definition so the default host of the Sitecore installation was used to generate the URLs. Also, we have requirements where URL should be formatted in certain ways based on business requirements. 

The drawback of these items which do not have site definition is that Coveo for Sitecore will consider these items are simple indexable Sitecore Content Items rather than a page where HTML binary can be generated. When looking at the Content Browser, we can see huge number of Sitecore Items rather than HTML. 

Content Tree Structure:

In Coveo for Sitecore, there are many pipelines through which we can manipulate the content. In this case, the manipulation is required to set the context site and then use the custom ItemUrlBuilder to get the required URLs and it can be sent to index the pages. 

On a higher level, Coveo for Sitecore will run through these pipelines and processors.

For the item which are under a site context, clickableUri's are generated properly and Coveo for Sitecore will be able to send the request, generates the response HTML and send the indexable content to Coveo. For the items which are not under a Sitecore Site context, the default 'website' site definition will be used as the Site context. then the default host of the Sitecore installation will be used. 

If we are using <serverUrl>, we are tied to one URL per Sitecore instance. In case if we have multiple sites in a Sitecore instance, serverUrl concept will be defaulting to only one domain. 

There is a pipeline which helps Coveo for Sitecore to get the Site definition for the current item. Name is  coveoResolveItemSite. In this pipeline, out of the box processor ResolveItemSiteProcessor helps to find the site definition. Since these items are not under a valid site definition, it will resolve to default 'website' site definition. We added another processor in this pipeline to check if these items are Shared pages or the Store pages and then set the site name for the item. 

Processor to Set the Context Site: Site name is hard coded for this blog post.

Config Patch for Processor: 

Once the Context Site is set, the custom ItemUrlBuilder which is used in the website will kick in. That will help in generating the proper URL for these Global items. 

You may face an issue when rendering the results from Coveo. You may need to add custom processor in coveoProcessParsedRestResponse pipeline. You can do it only if the rendered URL in search results page has issues.