Forum Replies Created

Viewing 15 replies - 1 through 15 (of 19 total)
  • Jono Alderson

    (@jonoaldersonwp)

    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?

    Jono Alderson

    (@jonoaldersonwp)

    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?

    Jono Alderson

    (@jonoaldersonwp)

    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?

    Jono Alderson

    (@jonoaldersonwp)

    Hi there,

    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 itemList schema 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 itemList on 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.

    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!

    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 (/#/schema/ etc).

    – 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!

    Hey Daniel,

    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:

    https://www.robertwent.com/blog/remove-yoast-html-comments-in-version-11-0/

    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! 🙂

    Forum: Plugins
    In reply to: [Yoast SEO] Rel=alt

    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

    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…

Viewing 15 replies - 1 through 15 (of 19 total)