sybrew / the-seo-framework

The SEO Framework WordPress plugin.
https://theseoframework.com/
GNU General Public License v3.0
411 stars 46 forks source link

Add more schema types+control over them on specific pages, primarily Person and Organization #543

Closed ViktorSander closed 3 years ago

ViktorSander commented 3 years ago

I just tried the "Articles" extension to get more schema, but I quickly found out that it gives us very limited control over what types of schema we want on each page.

For example, we have big guides on our pages that we want to mark up with correct schema, but we also have about pages, contact pages, and similar that we want entirely different schema for. At the moment we have to categorize everything as some sort of article which is bad and becomes misleading to Google.

With the increased importance of EAT we need more schema types for about pages and other miscellaneous pages.

Some examples of important schema we need to apply to certain pages: WebPage SameAs Author isPartOf inLanguage

Other schema types that will most likely become more relevant in the coming years: Citations (Schema property) reviewedBy (Schema property)

LeBaux commented 3 years ago

Hey Viktor, thank you for the question. Articles extension is meant just for articles and posts, as per description. Perhaps we should make it more clear.

This extension is meant to take the data present in your WordPress settings, TSF settings and in the post/article itself (ref. Usage) and output Article type of structured data. It also ads Google News Sitemap, allowing you to show up in the news section of Google search, provided Google deems your website newsworthy and authoritative enough.

output structured data exclusively for your articles/posts.

For example, we have big guides on our pages that we want to mark up with correct schema, but we also have about pages, contact pages, and similar that we want entirely different schema for. At the moment we have to categorize everything as some sort of article which is bad and becomes misleading to Google.

You should not do that with Articles extension, it might definitively backfire.

With the increased importance of EAT we need more schema types for about pages and other miscellaneous pages.

One of the perks of TSF is that we don't sell speculations as features. If anyone told you, that schema has anything to do with eat, I'm fairly confident they were lying. Official Google guideline on E-A-T is:

The only guidance Mueller offers about E-A-T is that it’s something used by quality raters guidelines and that it’s not a ranking factor. Reported by SEJ:

As for how to obtain expertise, authoritativeness and trustworthiness, this is all Mueller had to offer: “We don’t have any explicit information with regards to what you need to do there.” Expertise, authority and trustworthiness are important qualities for a web page to have. They are the qualities of a web pages that Google aspires to rank. But those aren’t actual metrics or ranking factors. There is no evidence or hint of evidence of such a metric. They are simply qualities of a high-quality web page. So it’s good to use that as inspiration for creating web pages.

However, we can't know everything so if you have a trustworthy resource disproving Google's official position, I more than welcome it.

Lastly, you mentioned other schema types. Please note, that marking up websites with schema data that are not abstracted from website content itself, is considered black-hat SEO.

I will give you an example. Say you want to use recipe schema. Unless the recipe itself is present on your website, you are hurting your SEO. In this case, it is best to use a recipe plugin, that not only helps you to put a recipe on your website but outputs schema data. RecipePress Reloaded is such a plugin, for example.

Other schema types that will most likely become more relevant in the coming years:

I understand you want the latest and the best in SEO. One schema markup was requested over and over again. It was FAQ schema. We were hesitant to add it for 2 reasons — First, we would actually have to make a Gutenberg block to output FAQ on the frontend. Remember, this was at the time where Gutenberg was (and still is) violently changing, not to mention it is built on new technology (react.js) never used in WordPress before.

Second, the actual evidence on the usefulness of FAQ schema was questionable. Here is the timeline:

If we implemented this feature, now we would be stuck with largely useless code inside our plugin to maintain forever. By now Google is smart enough to pick up FAQ automatically from site structure. Webmasters who rushed to implement it probably just helped to train the AI model. Note that TSF is also the safest SEO plugin ever, 5 years consequentially. It is in part because we test and use vetted technology and practices.

Part of my job is to protect TSF users from wasting their time on SEO speculations. Especially premium users, like yourself. We believe the whole SEO industry is overcomplicating SEO for the sake of making it complicated. After all, why would you buy their expensive SEO tools otherwise? Same goes with WordPress SEO plugins, you will find others have 300 features that have almost no bearing on ranking. If any.

Of course, we are open to discussion about new features and I hope you don't take this as a general reluctancy to do new things. Couple days ago Barry Schwartz compiled list of recent myths about ranking factors, it is a good read. I also recommend my all-time favourite, Guide to the biggest SEO myths by Bill Slawski. It offers a great framework to help everyone approach SEO systematically and critically.

I'm not saying we won't implement any new schema data, but we don't jump on trends and do our due diligence. I am happy to dive into details of this topic if you want. Have a nice weekend! Regards, Pierre.

ViktorSander commented 3 years ago

Thank you for the detailed reply! I do appreciate your diligent and critical approach, that's why we chose you. Most other plugins seem bloated without having the users' best interests in mind. And that's also why we want more schema options through you so we don't have to take a chance on trusting other plugins. We'd be happy to pay extra for it too. We've had so many bad experiences with plugins bloating and slowing down our site. I can tell you that we immediately saw a speed increase when we switched from Yoast to TSF.

I realize this thread now becomes a mix of both feedback on "Articles" and a feature request for other schema-types. Should I create 2 different threads instead to keep it separated?

Hey Viktor, thank you for the question. Articles extension is meant just for articles and posts, as per description. Perhaps we should make it more clear.

This extension is meant to take the data present in your WordPress settings, TSF settings and in the post/article itself (ref. Usage) and output Article type of structured data. It also ads Google News Sitemap, allowing you to show up in the news section of Google search, provided Google deems your website newsworthy and authoritative enough.

That was quite clear, although I hoped for the ability to turn it on/off for specific posts. Since we have a mix of articles and non-article pages we can't use the Articles extension on our pages. If we could either turn it off on specific pages, or choose "WebPage" instead of "Article", that would make the extension far more useful.

One of the perks of TSF is that we don't sell speculations as features. If anyone told you, that schema has anything to do with eat, I'm fairly confident they were lying. Official Google guideline on E-A-T is:

The only guidance Mueller offers about E-A-T is that it’s something used by quality raters guidelines and that it’s not a ranking factor. Reported by SEJ:

As for how to obtain expertise, authoritativeness and trustworthiness, this is all Mueller had to offer: “We don’t have any explicit information with regards to what you need to do there.” Expertise, authority and trustworthiness are important qualities for a web page to have. They are the qualities of a web pages that Google aspires to rank. But those aren’t actual metrics or ranking factors. There is no evidence or hint of evidence of such a metric. They are simply qualities of a high-quality web page. So it’s good to use that as inspiration for creating web pages.

However, we can't know everything so if you have a trustworthy resource disproving Google's official position, I more than welcome it.

Recently Google has been cracking down on pseudoscience and stuff like that. Isn't that EAT?

For example, I would like to make sure Google associates our authors' twitters, Google Scholar profiles, about pages, etc with them. Since there are many people with the same name, Google might confuse our authors with other less trustworthy people. That's an example where the "SameAs" schema would be of great use.

I agree that structured data is not a direct ranking factor, as Mueller have said. But he also says structured data can help Google target our content better when it understands it better: "SD can make it easier to understand what the page is about, which can make it easier to show where it's relevant (improves targeting, maybe ranking for the right terms)." https://twitter.com/JohnMu/status/980902538865205248 .

I want to use schema to help Google understand who our authors are, who we as a company are, and what our content is. If they don't understand that, how could they then judge our expertise, authority, and trustworthiness?

An example, I've noticed that we sometimes gain "HowTo" featured snippets in the serp, but they are often wrong or confusing because Google used the wrong list of items from our article. If we could clearly define each step with HowTo schema, that problem would be solved.

Lastly, you mentioned other schema types. Please note, that marking up websites with schema data that are not abstracted from website content itself, is considered black-hat SEO.

Thank you, I will keep this in mind. We have no intention of misrepresenting our website or our content.

Other schema types that will most likely become more relevant in the coming years:

I understand you want the latest and the best in SEO. One schema markup was requested over and over again. It was FAQ schema. We were hesitant to add it for 2 reasons — First, we would actually have to make a Gutenberg block to output FAQ on the frontend. Remember, this was at the time where Gutenberg was (and still is) violently changing, not to mention it is built on new technology (react.js) never used in WordPress before.

Second, the actual evidence on the usefulness of FAQ schema was questionable. Here is the timeline:

If we implemented this feature, now we would be stuck with largely useless code inside our plugin to maintain forever. By now Google is smart enough to pick up FAQ automatically from site structure. Webmasters who rushed to implement it probably just helped to train the AI model. Note that TSF is also the safest SEO plugin ever, 5 years consequentially. It is in part because we test and use vetted technology and practices.

Part of my job is to protect TSF users from wasting their time on SEO speculations. Especially premium users, like yourself. We believe the whole SEO industry is overcomplicating SEO for the sake of making it complicated. After all, why would you buy their expensive SEO tools otherwise? Same goes with WordPress SEO plugins, you will find others have 300 features that have almost no bearing on ranking. If any.

Of course, we are open to discussion about new features and I hope you don't take this as a general reluctancy to do new things. Couple days ago Barry Schwartz compiled list of recent myths about ranking factors, it is a good read. I also recommend my all-time favourite, Guide to the biggest SEO myths by Bill Slawski. It offers a great framework to help everyone approach SEO systematically and critically.

I'm not saying we won't implement any new schema data, but we don't jump on trends and do our due diligence. I am happy to dive into details of this topic if you want. Have a nice weekend! Regards, Pierre

I understand your dilemma. And I think tying it to Gutenberg could be a mistake. Personally, I disabled Gutenberg first thing when it was released, too buggy and clunky. However, I think you can implement more schema without tying it to Gutenberg. I've heard people use custom fields to implement custom schema types such as FAQ or HowTo to their posts. Please correct me if I'm wrong, I'm not well versed on the technical issues.

Have a nice weekend you too!

sybrew commented 3 years ago

[...] although I hoped for the ability to turn it on/off for specific posts

Already slated for the next (significant) release of Extension Manager. See https://github.com/sybrew/the-seo-framework/issues/523 😄

As for all the other structured data features that are interesting, some of which you've already mentioned, see https://developers.google.com/search/docs/guides/search-gallery. Google has been churning through a lot of those; they keep trimming and expanding the list.

Now, we only cover the ones for which we can infer data for from WordPress. For everything else, such as FAQ or Review, we'd have to know certain content is present--i.e., respectively, a FAQ section or a visible star-rating.

Because we focus solely on meta-generation, and not on content-generation (we're limited on development resources), we're not ready to implement these features. Moreover, you said you disabled Gutenberg--yet that's precisely where we'd like to put it.

As an aside, we do not like to mingle with third-party solutions like custom fields and shortcodes. As Matt Mullenweg put it:

The idea with blocks was to create a new common language across WordPress, a new way to connect users to plugins, and replace a number of older content types — things like shortcodes and widgets — that one had to be well-versed in the idiosyncrasies of WordPress to understand. […] It was time for a design paradigm that allowed us to move past the messy patchwork of shortcodes and text.

Nevertheless, more often than not, plugins are readily available that generate/formulate content and attach structured data to that. For example, WooCommerce fully supports Product markup for their product pages, so we don't have to implement that.

In a future update, we're going to tackle how structured data is generated. It's the last thing that needs a rework for me to be 100% happy with the code quality. Doing so will probably require me to implement "sameAs" types. See https://github.com/sybrew/the-seo-framework/issues/440.

Until then, I'm afraid you'll have to fill in the gaps manually via another plugin, like the aptly named "Schema", which should work alongside TSF without much hassle.

P.S. You can thank @LeBaux for this fancy new label I just created and attached to the issue 😅

ViktorSander commented 3 years ago

@sybrew , I understand your reasoning and I look forward to your upcoming releases!

Until then, I'm afraid you'll have to fill in the gaps manually via another plugin, like the aptly named "Schema", which should work alongside TSF without much hassle.

Thank you so much for the suggestion. It's great to know what plugins are compatible with TSF, it's always a hassle trying to figure out compatibility.

P.S. You can thank @LeBaux for this fancy new label I just created and attached to the issue 😅

Love it! xD Feel free to close this one.

sybrew commented 3 years ago

My pleasure! Thank you for going out of your way to leave this lovely review. Cheers, Viktor! 😃