Jono Alderson

That’s wonderful – thanks for the feedback!

Thanks John, that means a ton coming from you!

You can see that function doesn’t run if the permalink structure hasn’t changed. In your code, you’re not changing the permalink structure, you’re switching out the values of the slugs.

Hi,

I’ve been looking at this, and I think that there might be an easy fix.

If I’m understanding the approach correctly, it looks like you’re just switching out the slug variable, but not triggering any of the actions you’d typically want WordPress to run in such a case (e.g., flushing rewrites via flush_rewrite_rules).

It’s worth noting that we do update our indexables table on update_option_permalink_structure (and update_option_category_base + update_option_tag_base) but these never fire in your setup.

Perhaps you could try running update_option_permalink_structure as part of your save process?

No problem! ??

Hi!

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 noindex directive 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?

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.

• This reply was modified 4 years, 5 months ago by Steven Stern (sterndata).
• This reply was modified 4 years, 5 months ago by Jono Alderson. Reason: tidying

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 www.ads-software.com, 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/