Does Tabby support pushState?

Please can you post a link to pages where I can read about google, yahoo and bing’s SEO requirements in reation to this as I cannot find anything that states what the specific requirements actually are.

I don’t think this would apply to many tabbing scripts including the one included in the plugin as the tab content is in the page markup rather than being added via ajax after the initial pageload.

You’re right, I shouldn’t have said ‘requirements’. But I’m sure you’re aware that spiders and bots from the main searching tools won’t index the contents of a page that is hidden (whatever ‘hidden’ means, including any page/post/site with tabs on it).

So there was the hashbang solution (#!), which Google still supports, and then since 2012 everyone recommends using the browser’s history manipulation.

As far as I’m aware -please correct me if I’m wrong-, any content that goes behind a tab isn’t indexed unless there’s some sort of indication that those contents are in fact another page/post with its own unique url, therefore the hashbang/pushState solution. Even with the content being in the page markup, but actually invisible on initial page load.

Now, I know Tabby is one of the best tabbing solutions out there and I know nothing about code. But when googling for a tabbing solution, this issue was all around the place. That’s why I’m asking.

This first article does even mention your plugin:
https://www.web-savvy-marketing.com/2015/02/wordpress-accordion-and-tabbed-content-negatively-affect-seo/

This one has some words from Google itself:
https://www.seroundtable.com/google-hidden-tab-content-seo-19489.html

The next one is mainly about Ajax, but also explains the pushState solution. Of course, there are a lot more that dig into that and the browser’s history manipulation:
https://moz.com/blog/create-crawlable-link-friendly-ajax-websites-using-pushstate

And finally, Matt Cutts’ direct answer to the question:
https://www.youtube.com/watch?v=yiAF9VdvRPw

After some research, I found many jQuery tabbing developments that include some ‘url’ appending solution for this indexing issue, many of them didn’t include any Ajax. But they have other issues with responsivity, bad coding or being very buggy.

So obviously I went for a plugin that is well-established and maintained, but I need to be sure that my pages will be correctly indexed.

Thanks in advance.

PS- Don’t get me wrong, but you shouldn’t mark this thread as ‘resolved’, since you asked me for some clarification.

The thread was marked as resolved as you did not respond within 24 hours of my reply. In my experience if someone is going to reply they normally do so within 24hrs, and after that it is unlikely.

This plugin does not modify the default behaviour of the responsive tabs script it is build on. The full content of the tabs is visible in the page source and becomes hidden and shown via javascript.

Content in tabs will normally indexed by google but may be assigned lower weight as it is not visible on page load. It seems reasonable that the primary content of the page would be visible on page load.

I have performed some tests on sites I have made that use the plugin and have confirmed to myself that text inside the tabs is indexed by google and the page can be returned in the search results when searched for. It may be worthwhile conducting a similar test on your site if you are concerned about this.

Ok Michael, thank you very much.

If I can make a suggestion, I think it would be reasonable to request an url change for each tab, so all pages will rank the same.

Some sites -like mine- don’t have a ‘main page contain’ but sections of it, like Neighborhood and then House1, House2, etc, or Overview and then more detailed sections of an item.

Obviously, every content will be indexed and rank somehow. But sometimes one can’t rely only on a ‘main content’ tab. I bet not many users know this caveat and wonder how they could rank higher without any dirty trick, while their content is clearly better than the ones from their competitors.

Again, thanks for the quick and clear response.

I’ll investigate whether the url change can be achieved without breaking backwards compatibility or any other implications.