Jono Alderson

That’s an interesting question; I’m on the fence!

I think it’s still useful to output the schema code. You might not want Google to index a page, but you might still want them (and other consumers, like Facebook, etc) to understand what that page is about. You might also rely on pieces of the schema in your analytics setup, for example, and still want that to be present.

In my opinion, I don’t think that there’s any harm in leaving it on the page, though I’m happy to explore – did you have any specific concerns about it being present?

Hi @pro99, it looks like your theme already contains lots of inline structured markup, and it’s those pieces which are returning errors – not the bits which the Yoast plugin is outputting. You can investigate this by clicking on the output of the structured data testing tool, and it’ll take you to the HTML markup in question.

Depending on your theme (how it’s built, where it’s from, your development resources), it may be feasible to disable or remove some of that mess! ??

Hey @dmillersg77, this isn’t something we support at the moment, but I think it’s a good feature request. I’ve opened an issue in our GitHub repository – you’re welcome to chip in her: https://github.com/Yoast/wordpress-seo/issues/12719

Here we go: https://github.com/Yoast/wordpress-seo/issues/12718

Thanks, this is a good catch. I’ve opened an issue in our GitHub repo – you’re more than welcome to chip in there: https://github.com/Yoast/wordpress-seo/issues/12717

Hi @ov3rfly, I don’t think that this is a bug. Our spec allows for the use of ‘virtual’ URLs in IDs, to ensure that we have a logic and consistent structure.

More specifically, the ID is a distinct property from the URL/URI of a resource, so, spiders shouldn’t be (stupid enough) to assume that it’s a valid URL which they can follow.

I’d be happy to consider changing this to /person/{{person-name}}/#person for cleanliness when author archives are disabled, though!

Sorry, the bracket’s a typo on my part.

Let me clarify – loading/accessing the sitemap and its children works fine. However, any child sitemaps return a 404 HTTP header status, even though the page displays correctly…

Hi Sterling,

Any of the child sitemaps of https://www.daysoftheyear.com/sitemap.xml (e.g., https://www.daysoftheyear.com/sitemap-misc.xml) return a 404 header status ??

Hi Sterling,

Certainly: https://www.daysoftheyear.com/sitemap.xml

I’m also using the GUAR Google XML Sitemaps plugin to add support for custom post types; I suspect that this may be where the problem lies?

Might be an easy fix if so!

sterlo,

Your fix seems to work for /sitemap.xml, but not any of the child sitemaps – these are still returning 404 errors ??

Loving the beta, but having some minor issues… It appears that requests for any of the sitemap URLs are returning a 404 header status, rather than a 200, which is triggering errors in Google Webmaster Tools etc.

Easy fix?