Canonical Tag on Front Page
-
Hi,
the canonical tag on my static front page is broken. On the pages 2, 3, 4, etc. the canonical tag points to page 1.
I use the latest plugin Version 2.7.0.
Thanks!
-
And I don’t see any rel/prev links on my paginated static front page. Please take a look: https://dev.promicabana.de/wordpress/page/2/
In the categorys and tags it works just fine.
I deactivated most of my plugins, but the issue persists.
Thank you!
- This reply was modified 8 years, 1 month ago by bichareh.
Update:
I testet with Version 2.6.6 – it shows indeed the correct canonical tags! In Version 2.7 it’s broken again.
And in 2.7 it shows on my front page no prev/next links. In 2.6.6 it shows only the prev-link. Weird!
Could you please fix this issues?
Thank you! ??
Hi Bichareh,
This seems to be an issue with Visual Composer.
Looking at thetdBlock
script in the source, even WordPress doesn’t recognize this as a paginated system.I’ll take a look at it as soon as possible.
I’m afraid this issue lies with Visual composer not correctly injecting<!--nextpage-->
and/or adjusting thepage
andpaged
query variables but this is merely a guess.Your previous post suggested that openly checking for page numbers isn’t the right way, and you were right.
The improvement within the code that followed (which is taken directly from WordPress core) caused the pagination to fade away when none has been correctly provided. This explains the different behavior between 2.6.x and 2.7.0.I’ll keep you posted on any new findings. Cheers!
Hi,
did you have the time to take a look at this matter? I badly want to change my old SEO Plugin (not Yoast), because my rankings are like shit.
Thank you ??
Hi @bichareh,
The issue (based on assumption)
I finally got my hands on a copy of Visual Composer (through a premium theme from one of my customers), and I’ve tested it out.The pagination I put out on the front-end through Visual Composer is achieved through AJAX (JavaScript)… unfortunately, I was unable to replicate your website’s layout; thus no pagination could be added.
However, as I was working with Visual Composer, I noticed that it does carry its own pagination query in-line as JIT (Just In Time). This means that WordPress isn’t notified in time (before action ‘init’) about the pagination, and therefore The SEO Framework nor WordPress could not be aware of such situation before the page is written.
As you might have already noticed, The SEO Framework outputs its content at the top of the website. This is the perfect (and only) place for such content. As it’s within the
<head>
tags.
By default, the way the page is handled is already determined by WordPress. Visual Composer comes after that.
It’s perfectly handled by their plugin, but other plugins require adjustments to work with it.It is however not impossible — but it requires a dead-on adjustment towards Visual Composer from The SEO Framework.
The planned patch
All of the above has been formulated neatly in a GitHub Issue: 41.Unfortunately, I currently do not have the man-power nor monetizable capacity to develop such adjustment. Especially the latter is stressed at the moment, which is also the reason development on The SEO Framework’s base plugin has been halted for the time being (but 2.8.0 is still planned for December 2016). I hope you understand!
A (temporarily) resolution
In the meantime, I believe it’s best to disable the canonical URL on the paginated pages, if you wish to have the secondary+ pages to be indexed.
Currently, as I look into the source of the said website (non-dev version), I can see that the second+ pages havenoindex
assigned. This actually contradicts what you’re trying to achieve.If you require assistance implementing this (correctly), do let me know and I’ll get back to you! ?? Please also tell me which SEO plugin you’re currently using, because it’s hard to tell with all the source minification.
I hope this all clears things up. Cheers!
- This reply was modified 8 years ago by Sybre Waaijer.
Hi Sybre,
thanks for your answer!
I temporarily activated the Version 2.6.6, to get at least the right canonical tags on my front page. The only issue now are the next-prev-links. It shows only the prev-link. I don’t know if that is bad or SEO/Google.
To “noindex, follow” page 2, 3, etc. of my front page is actually the right move, don’t you think? Because it’s more or less “thin” content. The follow up pages of my tag archives are “noindex, follow” too.
Maybe you have more experience/knowledge if this is the right thing to do? I don’t want to flood google with thin content or useless stuff in order to achieve a higher ranking for my post pages.
I temporarily deactivated the html minifaction, in case you want to take a closer look on my site. I’ll be happy if you got some tipps for me. ?? And of course the improvement regarding the deactivation of the canonical tag on paged archives. Looking forward to your answer. :))
Hi @bichareh,
To “noindex, follow” page 2, 3, etc. of my front page is actually the right move, don’t you think? Because it’s more or less “thin” content. The follow up pages of my tag archives are “noindex, follow” too.
That’s absolutely correct! As long as there are no
nofollow
tags, all these pages are still looked at for links, but the page itself will not be indexed, thus preventing thin content. ??
My comment (“This actually contradicts what you’re trying to achieve.“) was a mistake.The incorrect pagination has been fixed in 2.7.0, among many other improvements.
Let me know if you’ve updated the plugin, no “new bugs” have been found since; it was a maintenance release after all. From there I can evaluate improvements.
Thanks and have a great day!
Hi,
I updated to 2.7.0, but as I mentioned a few posts above, the canonical tag is now incorrect on the paginated front page pages. ??
Now I have to remove the canonical on all noindex-pages (also in the tag archives & categorys, right?), like you said above. But how?
Btw…your Framework Extension Master Plugin creeps the s*** out of my server. ?? After activation I’ll get a Error 500.
Hi @bichareh,
Oh! That’s a new bug… but an intentional one.
This is because of this SEO issue.This does mean the core issue (unable to detect pagination) is valid (which was based on assumption).
To evade this issue, I believe this filter (which can be added to your theme’s
functions.php
file) should work; whilst keeping the security measurement in-tact… but only on your website’s scenario:add_action( 'the_seo_framework_do_before_output', 'my_homepage_content_pagination_fix_start' ); /** * Adjust multipage JIT. */ function my_homepage_content_pagination_fix_start() { add_filter( 'content_pagination', 'my_homepage_content_pagination_fix', 10, 2 ); } /** * Let The SEO Framework think there are multiple pages on the homepage. * Otherwise, pursue default behavior */ function my_homepage_content_pagination_fix( $pages, $post ) { if ( is_front_page() ) { //* Blindly inject multipage by using 2 ID's. $pages = array( 1, 2 ); } return $pages; } add_action( 'the_seo_framework_do_after_output', 'my_homepage_content_pagination_fix_end' ); /** * Remove multipage JIT filter. */ function my_homepage_content_pagination_fix_reset() { remove_filter( 'content_pagination', 'my_homepage_content_pagination_fix', 10 ); }
The functions above will let The SEO Framework always assume there’s pagination going on on the front page. After its assumption, it will reset the filter to its default value. So WordPress and other plugins can interact normally again (if WP_Query is re-initiated).
Please note that the code above has not been tested.
About the 500 error of the Extension Manager:
The plugin requires PHP 5.5 and higher. Which more than 50% of the websites don’t have. It’s built with the future in mind :).
Nevertheless, I’m very interested in knowing what caused the 500 error. Do you have an error log? ??Cheers!
- This reply was modified 8 years ago by Sybre Waaijer.
Hi again,
thanks for the fix! But it fixed nothing. ?? I also thought it would be better to deactivate the canonical tag on pages with noindex?
Maybe you got an support-email and I send you my login credentials to take a closer look?Regarding the plugin-issue. I have PHP 5.5.9. The Error log…
[Thu Nov 03 11:56:16.724415 2016] [fcgid:warn] [pid 7950] [client 188.108.33.82:50986] mod_fcgid: stderr: PHP Fatal error: TSF_Extension_Manager\\API has colliding constructor definitions coming from traits in /var/www/vhosts/h1.v12435347.campusvps.de/dev.promicabana.de/wordpress/wp-content/plugins/The-SEO-Framework-Extension-Manager-master/inc/classes/api.class.php on line 234 [Thu Nov 03 11:57:48.240587 2016] [fcgid:warn] [pid 7950] [client 188.108.33.82:51028] mod_fcgid: stderr: PHP Fatal error: TSF_Extension_Manager\\API has colliding constructor definitions coming from traits in /var/www/vhosts/h1.v12435347.campusvps.de/dev.promicabana.de/wordpress/wp-content/plugins/The-SEO-Framework-Extension-Manager-master/inc/classes/api.class.php on line 234, referer: https://dev.promicabana.de/wordpress/wp-admin/update.php?action=upload-plugin
Thanks again for the BEST support ever. :))
- This reply was modified 8 years ago by bichareh.
Your code only made my front page look weird. It removed my featured articles section and added the a “1”. :-O
Hi @bichareh,
Thanks for testing the code! I didn’t expect it to propagate towards other items. Unfortunately, it did :(.
The canonical URL essentially tells Google they’re on the right (or wrong) page, and thus must assume everything on that page as such.
Without the Canonical URL, Google will always assume it’s on the right page.Disabling or enabling the canonical URL tag on pages with noindex available yields no extra value, other than making sure that the page is the correct one. It’s implemented for completeness and preventing issues (if any).
Assuming there are no issues, the following filter should be used to disable the canonical URL on no-index pages:
add_filter( 'the_seo_framework_rel_canonical_output', 'my_canonical_url_adjustments', 10, 2 ); /** * Empties the canonical URL (thus preventing output) if 'noindex' is set. */ function my_canonical_url_adjustments( $url = '', $id = 0 ) { $robots = the_seo_framework()->robots_meta(); if ( ! empty( $robots['noindex'] ) ) $url = ''; return $url; }
The filter above has not been tested.
Back to the Extension Manager 500 error:
The error is outputted because of PHP bug #65576.
This has been fixed on the PHP releases of 22 Jan 2015, requiring therefore:
– PHP 5.5.21 or later
– PHP 5.6.5 or laterEssentially, I need to update the requirements more specifically :). Unfortunately, I can’t evade this issue; as it’s a fundamental item in its plugin security. It’s currently used in 17 (and counting) of the plugin’s classes.
I hope this helps! ?? Cheers!
P.S. In order to prevent any legal issues, I must decline website login credentials for support.
Hi,
thanks again! Your code works, but only on all not pages that are not related to the front page (tags, categorys, etc).
The reason is the one above: Your plugin doesn’t detect if it’s page 2, 3… and therefore it does not add the “noindex” tag on these pages.
Sorry to bother you again. ??
I tested your first code in my dev environment and it works. Unfortunately not on my productive site. Thats weird!
- The topic ‘Canonical Tag on Front Page’ is closed to new replies.