Yoast & rel canonical for paginated Wordpress URLs

[aactive]

Hello, our Wordpress blog at http://www.jobs.ca/career-resources has a rel canonical issue since we added pagination to the front page and category-pages. We're using Yoast and it's incorrectly applying a rel-canonical meta tag referencing page 1 on page 2, 3, etc. This is a known misuse of the rel-canonical tag (per Google's Webmaster Blog - http://googlewebmastercentral.blogspot.ca/2013/04/5-common-mistakes-with-relcanonical.html, which says rel-canonical should be replaced with rel-prev and rel-next for page 2, 3, etc.).

We don't see a way to specify anywhere in Yoast's options to correct this behaviour for page 2, 3, etc. Yoast allows you to override a page's canonical URL, otherwise it automatically uses the Wordpress permalink.

My question is, does anyone know how to configure Yoast to properly replace rel-canonical tags with rel-prev and rel-next for paginated URLs, or do I need to look at another plugin or customize the behavior directly in my child theme code?

This issue was brought up here as well: http://cloudz.click/community/q/canonical-help, but the only response did not relate to Yoast.

(We're using Wordpress 3.6.1 and Yoast "Wordpress SEO" 1.4.18)

[evolvingSEO]

Thanks for posting this Shaun! People actually do come back and read these months to come and these Q&A's will return in search results, so you've made this a really valuable page for future readers - thanks!

-Dan

[aactive]

I've now fixed this issue by refactoring our child theme so the WP queries occur before the header (inserting the content later).

Because we're using a custom homepage template for the front page and a custom "category page" template, I've also had to modify Yoast's "canonical" and "adjacent_rel_links" functions to understand the pagination for those pages (otherwise Yoast simply detects these as "singular" pages and only applies the rel canonical pointing to page 1, regardless of the current page).

I used the following code to allow overriding Yoast in my child-theme's functions.php:

if (defined('WPSEO_VERSION')) {
    function custom_wpseo_override() {

global $wpseo_front;

remove_action('wpseo_head', array($wpseo_front, 'canonical'), 20);
    add_action('wpseo_head', 'custom_wpseo_canonical', 20);
    remove_action('wpseo_head', array($wpseo_front, 'adjacent_rel_links'), 21);
    add_action('wpseo_head', 'custom_wpseo_adjacent_rel_links', 21);
    }
    add_action('init','custom_wpseo_override');
}

[evolvingSEO]

Shaun

Great, thanks - happy to help!

-Dan

[aactive]

Hi Dan,

Yeah it must me some kind of conflict with the theme or another plugin... We're not using Thesis or Genesis but we have modified header.php in our child theme to replace the masthead markup (just stuff within the body tag). I just noticed the other day that both the theme (ExtraNews by ThemeForest) and Yoast are adding their own <title>tags, so there may be more conflicts than one.</p> <p>Marking your response as an answer because you proved that Yoast can insert the rel next & prev tags and you've helped me get to the point where I'm 80% sure it's a theme conflict. Thanks again!</p></title>

[evolvingSEO]

Hi Shaun

Yes in terms of keeping strictly to Google's guidelines, I agree that Yoast should in theory use either prev/next or canonical on subpages, but not both.

I am honestly not certain the settings it could be otherwise, as "subpages of archives" is the only one I know of that handles pagination.

Could there be another plugin or your theme (or custom coding in header.php) causing a conflict? One thing you can do is shut off other plugins one by one to diagnose. You can switch themes or switch to the default header.php file included with WordPress, but I (for obvious reasons) do NOT recommend doing that on a live website. I'm not sure if you have a testing environment.

Are you using a framework like Thesis or Genesis?  Sometimes those can cause unexpected things to happen as well.

-Dan

[aactive]

Hi Dan, and thanks very much for your response.

Per your screenshot, I believe it's not ideal that there's a rel canonical meta-tag pointing to the current partial page (page 2).

From the Google blog link above: "In cases of paginated content, we recommend either a rel=canonical from component pages to a single-page version of the article, or to use rel=”prev” and rel=”next” pagination markup."

They mention here https://support.google.com/webmasters/answer/1663744?hl=en (2nd last point) that it's optional to include a rel canonical tag like yours, but without the "Noindex subpages of archives" option enabled, it would probably cause your separate post pages to be indexed, which may or may not be ideal for you depending on how authoritative/complete each individual page's content is.

Yoast is definitely adding the rel prev & next meta-tags for you though, which is exactly what I need (minus the rel canonical). I wonder which exact setting is enabling that for you... We have very few Yoast options enabled/configured at all currently, but I don't see any that are specific to the rel prev & next tags.

I've tried enabling the "Noindex subpages of archives" per your suggestion, but it didn't result in any change in the meta-tags for my site (verified after caches cleared too).

Any other suggestions you have would be great. My colleagues want to keep Yoast for it's other features, so I may go the route of forking/modifying the Yoast plugin code to fit our situation if needed.

Thanks for your time!

[evolvingSEO]

Hi Shaun

Dan here, one of the Moz Associates - we're very sorry for the delay!

I've attached a screenshot of my own personal company site which uses the Yoast Plugin - just want to verify the code as seen here is what I would consider "correct" and best practice for WordPress pagination.

That code has not require any custom coding or anything. So either we need to get the Yoast settings correct, or something else may be interfering with Yoast.

Please first try going to: Yoast SEO->Titles/Meta and select "Noindex subpages of archives". This to my knowledge is the only setting that needs to be made to handle pagination correctly.

Let us know if that works - and again, apologies for the delay. Sometimes we have quite a backlog and don't pick up right away if the community has not appropriately answered a question.

Thanks!

-Dan

lRYcPOhI

[aactive]

Do the 30+ people who've viewed this question think it answered itself? I tried to be thorough, but was it too much to read? Or... Is this not a great place to ask such a question?