Fixing Bing SERP “See more” behavior

Discover how to fix Bing SERP 'See more' behavior issues with SiteLint's comprehensive guide.

Sometimes Bing displays a SERP snippet with sections based on your heading structure on your page and links See more.

However, this See more link doesn’t go anywhere because the hash part in the URL is invalid. The hash part of a URL, denoted by #, is commonly referred to as a fragment identifier. When placed at the end of a URL, it points the browser to a specific section of a webpage.

Example See more link on Bing SERP snippet:

https://www.sitelint.com/blog/what-is-a-single-page-application/#Single%20Page%20App%20Example%20Sites.

The Bing SERP snippet and its See more link contain the hash part (fragment identifier) that has the illegal character space %20. Hence, the link doesn’t point anywhere because it’s invalid. We need to fix it so that when the user activates the link, the browser will lead the user to the specified location under the hash ID.

What is the issue with the URL hash part in Bing SERP snippet under the See more link?

The hash part in a URL, denoted by the # symbol, is called a fragment identifier. It is used to point the browser to a specific section of a webpage. This allows users to link directly to a particular part of a page without having to navigate through the entire document. For example, http://www.example.com/#articleHeading would take the user directly to the section with the ID articleHeading on the webpage at www.example.com.

In our case the hash part is represented by #Single%20Page%20App%20Example%20Sites. The problem with that is that hash part contains illegal character: space %20.

The %20 in the hash part of a URL is a percent-encoded representation of a space character. It is used to replace spaces in URLs because spaces are not allowed in URLs. This encoding is part of the URL encoding standard which allows special characters to be included in URLs by representing them with percent signs followed by two hexadecimal digits that correspond to the ASCII code of the character.

Why doesn’t the browser take us to the element indicated in the URL hash part?

The HTML standard says:

When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element’s tree and must contain at least one character. The value must not contain any ASCII whitespace.

The reason for not scrolling to the specified section in the URL hash part is that the hash part contains an illegal character. In our case, that is the space, and it is encoded as %20.

How can we fix the behavior for Bing SERP snippet and See more link?

Assuming your HTML element id attribute has the following structure: [word]_[word]. It is represented by a word and the underscore.

Bing is constructing the hash part of the URL from the heading description. For example, if the heading has the description My example heading, then the hash part would be: My%20example%20heading.

Fixing behavior for the Bing SERP snippet and See more link can be done using the following code:

function setScrollPositionToElement(element) {
    if (typeof element.scrollIntoViewIfNeeded === 'function') {
      element.scrollIntoViewIfNeeded(true);
    } else if (typeof element.scrollIntoView === 'function') {
      element.scrollIntoView();
    }
  }

function isUpperCase(str) {
  if ((/[^\w]/).test(str)) {
    return false;
  }

  if (isNaN(Number(str)) && str.length >= 1) {
    return str === str.toUpperCase();
  }

  return false;
}

const hash = globalThis.decodeURIComponent(globalThis.location.hash).replace('#', '');

if (hash.length === 0 || isUpperCase(hash.charAt(0)) === false) {
  return;
}

const elementId = globalThis.decodeURIComponent(hash).replaceAll(' ', '_').toLowerCase();
const element = document.querySelector(`#${elementId}`);

if (element === null) {
  return;
}

setScrollPositionToElement(element);

You can test this behavior by going to the article What is a single page application and section Single page app example sites.