Thanks for reporting this issue!
I believe this might be another ID collision problem. This time, I traced it back to WordPress’ very own get_post_type().
Note that the category ID is
The page with ID
295is of type attachment:
Please keep in mind that the following is merely speculative from a code review. Moreover, ID collisions are difficult to replicate, so I truly appreciate any help I can get with this.
I believe this is an issue in combination with the “Apply
noindexto Media?` option, which is more than annoying. If you could affirm my speculation by temporary disabling that option, that’d be most helpful!
Please, don’t disable that option for any longer than you require for testing; it’ll ruin your ranking by allowing Google to index low-quality content in bulk.
Now, attachments aren’t added to the sitemap, so you have a few days before Google notices. Moreover, testing this only requires a minute 🙂
I also forwarded this issue to GitHub, for further investigation:
Hi there, disabled, tested, however it is still present. It’s not much of an issue as it’s a category page, but I thought it was odd as it was only one of them. Other category pages are indexed fine. I created this category recently, so maybe that is why.
I’m following the issue on GH too.
Thanks for looking into it – really impressed with SEO Framework, very glad I moved to it!
Thanks for looking into it!
With that, I have a few more follow-up questions:
- In the dashboard, what does the SEO Bar say for the category under “I”? Is it green, red, or blue?
- What’s the post count according to WordPress for the category?
- If you uncheck the “Apply
noindexto every second or later archive page?” option, does the tag disappear?
If your answers are either “1. blue, 2. 0, 3. no” or “1. green, 2. at least one, 3. yes”, then I suspect a plugin or theme conflict, where custom drop-in queries are registered for the categories.
1. https://i.imgur.com/FklPuGI.png, being indexed
2. 2 posts
3. Nope, does not fix it.
Thanks for the info! I’ll go back to the drawing board 😅
Thanks so much for the help and the plugin!
I need some more information regarding this issue. Could you help me out?
When you add this definition to your wp-config.php file, then you can actively debug the query via The SEO Framework’s debugger. Note that it requires PHP 7 or higher:
// Enables The SEO Framework debugging when ?debug_tsf=true is added to the URL. define( 'THE_SEO_FRAMEWORK_DEBUG', ( $_GET['debug_tsf'] ?? 0 ) === 'true' );
Now, this won’t work from our side because you’re using a caching plugin. However, if you log in, and add
?debug_tsf=trueto the URL, you will see a debugging box at the bottom of your page. This works on any screen, even in the admin.
Feel free to exchange
truewith a secret key, like
MyKey. This should then be reflected your query parameter added to the URL, e.g.
Could you make a screenshot or two of that box on the page that’s acting up?
I’m most interested in the second part: “WordPress Query at Meta Generation & Current WordPress Query”. You may send that confidentially via my contact page: https://tsf.fyi/contact
Added the debugging script, didn’t see the box. Added it like this:
And left the key as true.
That’s strange! Does it appear when you add the query string in the admin dashboard?
And, doesn’t it work when you’re logged in on the front-end, either? That’d mean that the standard
wp_footeraction doesn’t run, which is odd.
P.S. query parameters are split by
&, so that’d be
?example=42&debug_tsf=truein some instances.
Tried that too, not working. Did it wp-admin, no success.
Thanks for testing! And I’m sorry that I took away your precious time 🙁
If you added it to your theme’s
functions.phpfile, it wouldn’t work–that’s because the theme loads after TSF initializes its debugger.
If you add it to your
wp-config.phpfile, then it should work.
However, if you already tried that, could you try using this instead? It will force it to be enabled for all users, so you don’t want it enabled for too long:
define( 'THE_SEO_FRAMEWORK_DEBUG', true );
Thank you so much!
Thanks for that!
It seems that another plugin or theme is either overwriting WordPress’ global variable
$multipage, or the
max_num_pages. Either by accident or intentional, on that specific page… Which is odd, as none of your other archives are affected–maybe it matched “wordpress” for some reason?
This causes the pagination value to be at 0, which is one of the parameters TSF uses to detect empty queries, and so it deindexes the category.
If you’re proficient in coding, then I suggest looking for that globals variable through the active plugins and theme. If you’re not, then I recommend deactivating plugins one by one, until the error disappears.
- This reply was modified 4 years, 4 months ago by Sybre Waaijer. Reason: clarity
- The topic ‘No index on page that shouldn’t have it?’ is closed to new replies.