I presented the results of our Peak Ace test lab earlier this year at SMX Advanced. These tests shed light on a number of technical implementation points and how Googlebot would handle them.
One of my favourite tests was Google’s indexing iFramed URLs as well as their content. In my SMX Advanced presentation I discussed various scenarios that could lead Google to index an iFrame’s content and “assign” it to its parent URL.
In some cases, the parent URL can rank content that is only found in the iFramed URL, but not in the parent URL.
Naturally, people were excited and many follow-up questions were posed. Here are some of my answers.
Did the iFrame content come from the same domain as the domain that was being tested?
My example showed two URLs that live on the same domain: domain.com/test.html
would iFrame domain.com/tobeframedA.html
, so that test.html
could rank for content that only exists in tobeframedA.html
.
The same also works for externaldomain.com/tobeframedB.html
– which can still cause test.html
to rank for content only present in tobeframedB.html
, as well as for iFrames residing on subdomains. We tried every possible combination and concluded that it didn’t matter where the iFrame content was located.
You can block someone from loading your content in an iFrame. This indicates whether a browser should have the ability to render a page within an iFrame.
If iFrames were to be used with a non-indexed content page, would the parent site still rank for the listed content?
The parent URL will not be able rank for content from the iFramed link if the iFramed URL has a meta robots directive.
The same applies if you iFrame a URL which would be served with an XRobots noindex directive header directive or is actively blocked by robots.txt.
iFrames supports the loading="lazy”
attribute to speed up page speed. This would delay offscreen iFrames being loaded until a user scrolls close to them. This is a great way to speed up URLs that depend upon iFramed content loading times.
Google gives semi-hidden content (content which is usually found after ‘Read More’) full value?
Google doesn’t seem too fond of the “Read more” functionality. John Mueller questioned the use of the functionality in full. He made comments here and here. Mueller stated, “I don’t think you’d see a noticeable and direct change in SEO .”
It was tested to see if the technical implementation would make any difference.
The short answer is that it would be indexed, found, and returned, regardless of whether or not it were visible.
However, the snippet didn’t highlight content that was not visible during loading. Technical implementation did not make any difference, as long as the content was in the HTML DOM at loading. You can use display:none or opacity;0, visibility:hidden etc.
However, I believe it is impossible to set up a test that could give an accurate answer to the “full value” portion of the question.
Did you know that CSS implementation can fix duplication in certain content areas since it isn’t indexed?
I did however present some behavior I find quite interesting about CSS selectors. The technical explanation is that selectors like ?:before
create pseudo elements that are the first children of the selected element. This is often used to add cosmetic information to an HTML element.
This could be useful for SEO as Googlebot seems to treat it the same way it would Chrome on desktop/smartphone. The rendered DOM is unchanged, which is to be expected as it’s a pseudo-class. Therefore, the content within these selectors will not be indexed.
This could be used to prevent certain content being indexed but not allowing it to be displayed on the website. You might need to display content that is not considered “boilerplate”, such as shipping information or legal info, or you may want to create a specific content footprint. This opens up many options for further exploration.
Watch: Technical SEO Testing in 2022: Separating fact and fiction
Below is the complete video from my SMX Advanced presentation.
Search Engine Land’s first article was Technical SEO Testing: How Googlebot handles Iframes.