Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Too broad "is_multiple_terms_query" check in WPSEO_Frontend #8447

Open
2 tasks done
kallehauge opened this issue Dec 8, 2017 · 6 comments
Open
2 tasks done

Too broad "is_multiple_terms_query" check in WPSEO_Frontend #8447

kallehauge opened this issue Dec 8, 2017 · 6 comments

Comments

@kallehauge
Copy link

kallehauge commented Dec 8, 2017

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

Please give us a description of what happened.

When using external search-index plugins that have to specify all child terms that they want to query for when WP_Query contains include_children then the check fails and says that the archive page is a "multiple terms" page. This ends up adding robots => noindex in the head.

Example: A webshop have a product category with child categories (bikes > race-bikes).
If "race-bikes" does not have any children, then this page will be indexed but "bikes" will not.

It is possible to read more here in an ElasticPress issue where one of the contributors semi-concludes:

I tend to consider it as a Yoast SEO issue because...

I figure this is a regular case but I have only tested with ElasticPress but it would be awesome to hear what you feel.

Please describe what you expected to happen and why.

I expect taxonomy terms with child terms to be indexed with external search-index plugins so they will show up on Google 😅

How can we reproduce this behaviour?

  1. Install and enable WordPress + WooCommerce + Yoast + ElasticPress.
  2. Enable EP's WooCommerce feature.
  3. Go to a product category with child terms and inspect the DOM. The parent's term archive is now changed from robots => indexed to robots => noindex.

Technical info

  • WordPress version: 4.9.1
  • Yoast SEO version: 5.9.1
  • Relevant plugins in case of a bug: ElasticPress
@CarolineGeven
Copy link
Contributor

Thanks for your bug report. We've been able to reproduce the issue and have therefore labeled the issue as a bug.

Unfortunately we're not able to fix this at short notice. Currently we're focusing on issues that affect many users. We've concluded that this issue is not experienced by many users, therefore we are not able to fix this short-term. However, if more users are affected by this bug, we'll of course revisit this issue.

Additionally, we'd like to point out that we welcome contributions to our product. If you are able to submit a patch to fix this issue, we'll be able to get the bug fix through faster.

Thanks for your understanding.

@kallehauge
Copy link
Author

kallehauge commented Dec 8, 2017

It is, obviously, sad to hear that it will not get prioritised but I understand ☺️ And thank you very much for the fast response @CarolineGeven 👍

I'll see if I can squeeze in some time between Christmas and New Year's Day for a patch.

@pySilver
Copy link

Can you please add a filter to override this logic? There are cases when multiple multiple terms query wanted to be indexed

@monbauza
Copy link

Issue still relevant in latest version of the plugins: Yoast SEO 10.1.3, ElasticPress 2.8.2 and WooCommerce 3.5.7.

@monbauza
Copy link

Please inform the customer of conversation # 493461 when this conversation has been closed.

@PatrikJohnsson
Copy link

Hello,

I raised this issue via email sometime ago too, but was told to wait for the next updates, but nothing improved.

Are you looking to fix this, or are we expected to pay for licenses without issues being fixed? This is affecting a number of our sites and it would be nice to have it sorted.

many thanks,
Patrik

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants