MicroData, Rich Snippets, Structured Data

[Jim Holloman]

I appreciate the effort of the Joomla Developers and the Template developers to emit the desired MicroData.

However, I am experiencing many errors when my output is evaluated by the Structured Data Testing Tool at:
https://search.google.com/structured-data/testing-tool

Here is an example:

- - - - - - - - - - -
100 Blog Errors - standard Joomla and Protostar Template:
http://charlestonscvisitors.com/food-dr ... estaruants

A site with 3 references to "blog" in:
...\components\com_content\views\category\tmpl\blog.php
removed.

Has no Blog Errors:
http://hendersonvillencvisitors.com/foo ... estaurants
- - - - - - - - - - -

There are other areas in the code that is also emitting code that causes MicroData errors -- including more "blog" output.

Competitive websites in Wordpress that have essentially the same data are doing much better in the SERP (Search Engine Result Pages) than my website. I have set nearly all of the Titles and Meta Descriptions to what I would expect to be the best data.

I have to wonder if these MicroData errors are hurting my website. When I paste the code from the competitive websites into the Structured Data Testing Tool, there are much fewer errors.

Could someone that knows PHP and Joomla evaluate this and determine if updates are needed to eliminate the Micro Data errors?

Which is better? A webpage that has no microdata? Or, a webpage that generates a hundred Micro Data errors?

I don't like Wordpress. But, it seems to be doing a much better job with SEO -- using plugins such as Yoast.

[Pnkr]

you could just make a template override on blog output and make the desired changes.

[Jim Holloman]

Many thanks, Pnkr, you for your reply.

While I do not know PHP, I did manage to remove the Blog reference (I believe 2 lines were changed) in the blog.php file.

However, there is other PHP Code somewhere that is emitting the "Blog" itemprop that I have yet to be able to identify or locate. And, once again, this "blog" itemprop is being flagged as an error by the Google Structured Data Testing Tool.

If this undesirable situtation does exist, then it probably effects many thousands of users and IMHO, should be resolved at the source.

And, ideally, Joomla would be a CMS that does not require the content developers, or users, to understand OOP and PHP. That is the domain of the Joomla Developers. Personally, I find the structure and operation of Joomla at the code level to be very complex and beyond my ability to grasp.

I was reading about creating a Component - and discovered that you also have to develop a router Wow! Over my head! I know of a developer that switch from Joomla to Wordpress because he found it very difficult to create a Custom Fields Extension for Joomla.

I am very interested in seeing the Joomla CMS (Out-of-the-Box, as they say) become more popular. Resolving issues such as bad MicroData being emitted would certainly not hurt. I would prefer to have no MicroData emitted rather than bad MicroData.

Needing to know PHP and SQL is one of the arguments against Drupal. It also seems to be an argument against Joomla; but more so in regard to PHP than SQL.

[Per Yngve Berg]

It's not the Blog Itemprop that is the problem. It reports missing mandatory properties. You can make this going away by setting Author, Created/changed/Published dates to show.

[Jim Holloman]

Thanks for the reply, Per Yngve Berg.

The problem is the output is not a Blog. It is a Category Blog and as such the Author and as well as Created/Changed/Published dates are not applicable. Showing this information would be very confusing for the user -- and in each case the Author would be "Super User". Dates are completely immaterial.

One could consider the output to be a "Business Listing".

So, in the Menu, I changed the Menu Item from Category Blog to Category List and did not see any change in the output. The code still shows:
itemtype="https://schema.org/Blog"
itemtype="https://schema.org/BlogPosting"
itemprop="blogPost"

I did clear the Joomla and Firefox cache. Perhaps I did something wrong.

It looks like I will have to engage in the time consuming task of examining every .php. file to see which ones are emitting the Blog Information and attempt to remove the proper code -- while doing no harm. Or, perhaps I need to examine only the .php files associated with Views.

IMO, Google has gotten a little ridiculous with this Structured Data, MicroData stuff. It is a PITA. But, like all things Google, there is no option if you want to be found. Is ANYONE still using Yahoo and Bing?

[effrit]

Try make it as Per Yngve Berg suggested.
If errors will gone, just use css to hide this blocks (display:none)

[mbabker]

You can do the metadata as attributes of whatever HTML element you choose (including meta tags in the body), they don't HAVE to be printed on the page. One of the structured data attributes is a modified date, we don't print that on our company's blog posts but we do have it in the HTML markup.

Code: Select all

<div class="text-center createdby">
    Written by <span itemprop="author" itemscope itemtype="https://schema.org/Person"><span itemprop="name">Author Name</span></span><br>
    <span class="icon-calendar"></span>
    <time datetime="2018-04-11T17:00:00+00:00" itemprop="datePublished">Published: April 11th, 2018</time>
    <meta itemprop="dateModified" content="2018-05-10T13:53:22+00:00"/>
</div>

So in our info block we show the author name and published date, and put the rich snippet data in as attributes on the HTML elements. Note the meta tag, this one isn't displaying any information on the page but fulfill's Googles request that the modified date is there.

Note there was a feature proposal years ago as the result of a Google Summer of Code project to have configurable microdata in the core UI, this ended up being rejected as too complex.

[posurreal]

How can we handle the following schema errors for category blog view?

A value for the headline field is required.
A value for the image field is required.
A value for the publisher field is required.

I think I'll just override the category blog view in my template and remove the itemprop altogether. Then, use jsonld as a custom html module.

Is Joomla 4 planning to add these options to the category blog layout? If so, I will revisit the issue and restore the core default.