Forum Replies Created
In theory, those values should cascade. But in practice, different consumers work in different (and unpredictable, changing) ways. Documentation at this level of specificity is sparse, and there’s no definition of how things ‘should’ work – only how they ‘can’ work.
Furthermore, it’s not unfeasible that a question might have different languages for the ‘question’ and ‘answer’ parts. All of this makes it worth the (trivial) overhead of repeating the value. Also worth considering that gzip/brotli reduce the performance cost of this to near zero.
So, yeah, it’s potentially duplicate/redundant, but, better safe than sorry! 🙂
WordPress core only recently started automatically adding a
noindexdirective to search results pages (as of 5.7). Sites will need to update to take advantage of this (or you could run a popular SEO plugin), and, it may take time for URLs that have already been indexed to drop off.
Yep, a 500 error will definitely cause indexing issues. This is definitely the root of all of these problems.
Unfortunately, I’m not sure how you’d go about easily finding out why this is happening; it’s an odd situation, and one I’ve rarely seen in the wild.
I suggest I tag-team in our support team to run through some steps to rule out plugin/theme conflicts, and hopefully, we can narrow down the surface area.
It looks like you’re hosted with WP Engine, unless I’m wrong – it might be worth reaching out to them, too?
Well, I think that I’ve found the problem. It looks like your server is returning a 500 (error) response for that URL – and in fact, all URLs – even though the page is loaded correctly. That’s definitely going to cause Google/Twitter/FB etc to behave in odd ways.
I’m struggling to see anything from the outside-in which might be causing that; it’s likely related to your server/hosting setup, or something odd that your theme is doing. You mentioned that this was new-ish behaviour; perhaps something changed on the server-side recently?
It looks like you have two sets of opengraph/twitter meta tags on your page. One set is from Yoast, and the other is from the ‘Heateor Open Graph Meta Tags’ plugin. The values they both output are the same, so that shouldn’t break anything, but I’d like to rule it out as a potential smoking gun. Can you try disabling that plugin?
The short answer (and the good news) is that this isn’t a problem. Your FAQ markup is correct and will work correctly. Providing there aren’t any other problems, your FAQ content should be eligible to show up as FAQ results in Google.
The longer version (and the bad news) is, Google’s specification for how they handle FAQs, and how they handle “carousel” markup, are both… problematic.
There are a few moving parts, so please bear with me as a ramble…
- It’s good practice to use
itemListschema markup when you want to describe a list of things. In most cases, FAQ questions are a type of ‘list’, so it makes sense to describe them this way. We define a list, and we place each question inside of it. Without this approach, the questions are… ‘orphaned’ in the page.
- However, whenever you define an
itemListon a page, Google incorrectly assumes that you’re trying to be eligible for ‘carousel’ results (a concept which Google have invented, which doesn’t exist in schema.org).
- Conversely, there’s no precise approach in schema.org to say “This is a list of questions”, only, “this is a list, and, it contains questions”. Which brings me onto the next issue…
- Google’s specification handles this omission by requiring questions to be directly attached to the WebPage schema piece as the ‘main entity’ of the page. That causes a heap of technical and conceptual problems which I won’t get into in too much depth (you can’t conceptually have multiple main entities, and you certainly can’t have multiple types of main entities). Suffice to say, Google’s approach doesn’t work well in the real world, with the kinds of more complex and interconnected schema that we output.
So, to summarise:
- Our FAQ structured data doesn’t quite align with Google’s documented approach, but, it works, it’s more sensible, and it’s more sophisticated + robust.
- Google’s testing tools are a bit trigger-happy about carousel markup.
- Everything is fine.
In reply to: [PWA] How to best determine if a request returns service worker content?
Thanks! I have a few use-cases where I’m altering/adding HTTP headers, and don’t want to do this on service worker responses.
It’d awesome if we could get a
is_service_worker(), too, to keep this clean and consistent.
FYI, I’ve just run into this causing some problems on wordpress.org, and as such suspect that it’s a core WordPress bug which we need to squash somewhere upstream. I’ll report back if/when I make progress with diagnosing!Forum: Plugins
In reply to: [Yoast SEO] Search Console 404 error on schema url
Chipping in here.
There are a few moving parts here, so allow me to take a step back, if I may.
– The /person/ URL structure is syntax which we used to define the ID of author nodes in a previous version of Yoast SEO. That’s now changed to the new approach (
– The new ID structure we use on authors is more sophisticated than in other places (where we often just use a URL, or a derivative of the URL), and we’ll be gradually upgrading the rest of our schema to use this approach. Whilst it’s ‘conventional’ to use URLs as IDs, our approach is more robust, semantically correct, and interoperable. There’s no fault/error with it.
– Google crawl anything they find in a page’s source code, aggressively, including things which may not be valid links. They prefer to crawl first, assess the response, then determine what’s valuable/real or otherwise. It’s normal to see search console fill up with error reports for things which aren’t errors/URLs. Sometimes they’ll actively probe and explore dead ends intentionally to find new URLs, and sometimes they’ll re-check old URLs which no longer exist. This is indeed frustrating, and their reporting on this in Google Search Console is poorly worded/managed – but Google have behaved like this forever and will likely continue to do so.
– As I investigate, it looks like we don’t actually output a URL property on the author/person node, and we definitely should reference their profile/posts page. I’ll get that added to our roadmap now.
Hope this helps clear things up!
It looks like you fixed this, but just in case, the problem is likely with a plugin/filter that you’re using to strip Yoast metadata / HTML comments from your source code.
There’s a great guide to solving that here:Forum: Plugins
In reply to: [Yoast SEO] Schema.org being output regardless of search appearance setting
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/12719Forum: Plugins
In reply to: [Yoast SEO] Bug, outputs author archive url also if author archive disabled
- It’s good practice to use