Incorrect og:url When Searching a Given post_type

[nr5149]

• [x] I've read and understood the contribution guidelines.
• [x] I've searched for any related issues and avoided creating a duplicate issue.

Please give us a description of what happened.

When searching a given post type (https://www.example.com/?s=pantalon&post_type=product), what you get in og:url is https://www.example.com/search/pantalon/ (that will not search this post type in particular).

Please describe what you expected to happen and why.

og:url should stick to original URL (https://www.example.com/?s=pantalon&post_type=product). BTW the /search/ fragment in permalink cannot even be translated easily in WordPress (is this permalink really meant to be used? ;-) ).

How can we reproduce this behavior?

1. Search within a given post type.
2. Check OpenGraph on results page.

Technical info

• If relevant, which editor is affected (or editors):
• [ ] Classic Editor
• [ ] Gutenberg
• [ ] Classic Editor plugin

• Which browser is affected (or browsers):
• [x] Chrome
• [x] Firefox
• [x] Safari
• [x] Other

Used versions

• WordPress version: 5.4.2
• Yoast SEO version: 14.7
• Gutenberg plugin version:
• Classic Editor plugin version:
• Relevant plugins in case of a bug:
• Tested with theme:

[Djennez]

Hmmm, I believe WordPress is generating those links itself (when pretty permalinks are enabled), that's an assumption based on info from 2016: https://github.com/Yoast/wordpress-seo/issues/2094 . We're already disabling canonicals on search results pages due to this behavior. I am not sure if / how we should change og:url for this. @jono-alderson, got any thoughts on this?

[jonoalderson]

Ooh, this is an interesting conundrum.

So, we do indeed disable canonical URLs on these URLs (because they're set to noindex). However, we still construct valid og values so that there's a good user experience when these posts are shared.

But, you're right - the 'pretty' og:url values often won't map accurately back to the actual search query. I've also run into translation issues around the /search/ string, and I suspect that there are potential pitfalls there too.

Given that, I'm inclined to agree that we should use the 'raw' ('not pretty') URL for the og:url value, as no 'pretty' structure will ever correctly reflect any post type filters or other filters/modifiers (like ordering, etc).

For a more robust implementation, we should remove any invalid query parameters from the constructed URL, in order to reduce social equity fragmentation (sharing of URLs with various 'non-canonical' og:url values).

[jonoalderson]

So, my call would be to consider this a bug, but a very low priority one - there's negligable user impact, and no SEO impact. However, we should correct this for the sake of technical accuracy and 'correctness'.