If a certain post type is not getting indexed, or if you get a “The index table is empty” error when trying to re-index, the reason can be that this post type is not being indexed by FacetWP. For a post type to be “searchable”, the exclude_from_search argument of the register_post_type() function must be set to false.

If the above excerpt is indeed applicable to what I’m trying to do (I’m not a dev, so please bear with me ), how would one go about making VSEL events indexable?

I have a problem with Yoast indexable for quite some time with multiple sites, I have rewrite rules for custom post type and taxonomy structure for WPML translated archive page. Everything works fine unless we save a taxonomy term or a single post type. The indexable seems to trigger after saving a post and cause 404 only on the translated page. I need to save the permalinks each time to fix the 404.

I tried to reindex the indexable via WP-CLI wich cause 404 just like saving a term or post type. I also tried to debug in the core plugin files, I found that commenting a line in the set_started function insinde indexing-helper.php fix the 404 issues but I don’t want to always comment this line in the core files. Are you already aware of this issue, I was waiting for a fix but I had this problem for over a year so any help will be appreciated.

Here’s a video of the problem and the plugin file fix : https://www.loom.com/share/4cbed6f63e0b4cdcb7c505488653e527?sid=93e738a7-cb86-4dde-a0f8-75504f01a9f3

Thank You!

it going to more than 40GB after few days and when i review it 90% of errors is

wp_yoast_indexable’ doesn’t exist

or

wp_yoast_primary_term’ doesn’t exist

or

wp_yoast_indexable_hierarchy’ doesn’t exist

with the sql database name before it.

please help to resolve this. i search entire internet and found nothing.

thanks.

For example, on the page https://www.rephunter.net/blog/keep-the-ball-rolling/, the following entry appears, with the actual site name replaced with asterisks:

<link rel=”canonical” href=”https://www.oofdah.com/blog/keep-the-ball-rolling/” />
So the result is that the canonical entry is not pointing to our website at www.rephunter.net, but instead is going elsewhere.

Please note: because of changes we made described below, this wrong link is no longer present, and the canonical link is now as it should be.

The canonical link as far as I know is totally controlled by Yoast. However, we have never set up canonical entries at all.

As another measure, I grepped the entire code base but could not find anything in the code.

As a final step I looked into the Yoast tables in the database. In the indexable table, out of 600 rows, I found 17 rows that had in the permalink column references to the wrong URL. I checked the permalink for those pages, but they are not pointing to the wrong website but to the proper website.

As a test, I manually changed a permalink anyways and rechecked that table–it still was pointing to the wrong website.

Looking further into Yoast, I was able to run the “wp yoast index” command from the command line. The tables were re-indexed. However, the 17 entries are still pointing to the wrong website.

As a final step, I deactivated Yoast. After that those canonical entries pointing to the wrong site were no longer present on the pages in question.

I reactivated Yoast hoping that it might have fixed itself, but unfortunately the bad canonical links came back.

So the problem appears to be in Yoast, and somewhere it has got information about the wrong blog.

As an additional test, I manually updated the Yoast indexable table to change the permalink column on the 17 rows from the wrong website to the correct website. Then reactivated Yoast.

After those steps, the canonical entry is now correct. So the immediate issue is corrected. However, I would like to know how the indexable table was corrupted, as I suspect the problem could recur.

1. We first noticed that Wordfence was reporting hack attempts that it was blocking, but where the userid was from a different blog that we operate, but that should have no connection to the site in question. That is, there should not be a normal way for hackers to be attempting to use userid values from the other site. This was a mystery for several weeks.

2. Later we noticed that the home page of our blog had canonical and link tags pointing to the other site. This would lead spiders and bots to traverse the other blog, and would probably explain the mysterious hack attempts.

3. We could not see how to fix the issue. All of the documentation on changing canonical tags starts out with “go to the page” and change the Yoast canonical setting. However, we do not know of any way to “go to the site home page” in the WordPress admin section–you can only go to posts or pages. The site home page is not in the posts or pages. There might be a way to do this, but we could not discover it. If you did go to any site page that you could in the admin, the Yoast canonical field was empty.

4. Just browsing through the Yoast database revealed bogus entries. There were forty some rows in the indexable table that had in their permalink column entries pointing to the other blog property. For example, a permalink that should have had https://www.oursite.net/blog/ instead had https://www.othersite.net/blog/. The domains “oursite” and “othersite” are of course placeholders. Again, a complete mystery how this could happen.

5. I found that the Yoast Test Helper has a feature to reset the indexable table. I used this feature, and the indexable table had all rows removed.

6. After the indexable table was cleared, the canonical and next tags were cleared from the blog home page.

7. As expected, the indexable table was eventually rebuilt. However, there were no permalink values that had any references to the wrong blog.

8. Checking the canonical and next tags on the home page now have the proper values that point to the proper pages in the blog. So the effect of the problem appears to be fixed, but the root cause of what caused the problem is still unknown.

Bottom line: if your blog gets canonical links pointing to a foreign blog, clear the indexable table.

Thank you

is it possible to turn off this indexable feature or it must be done?

I have 700000 posts and after few days still didn’t finished, but i see that is hitting a lot of my DB server…