axlright

Thanks, Michael –

I appreciate you taking the time to clarify that this is expected behavior. I understand this is an uncommon use case. I can imagine there are others, like an archive of team members where you don’t want / need each team member to be indexed individually. Or in my case, the single certificates are not to be indexed for security, but the archive is to be displayed where people can search for a certificate if they have the number.

Regardless, I understand that it is expected behavior for an archive to not show in the sitemap unless at least one individual post is also shown in the sitemap.

In my case, I’ll turn the archive into a page template to get it into the sitemap.

Thank you!

Thanks Suwash, but what you are saying is not happening in Yoast. I have a CPT with the archive set to show in the sitemap. The posts are set to not show in the sitemap. None of the posts are set to noindex. However, the archive does NOT show in the sitemap.

It doesn’t seem anyone can help with this. It seems to be a bug / broken part of Yoast.

Thank you, Maybellyne-

The custom post type was created with CPT UI.

I don’t understand your question “If I understand correctly, you have turned OFF the option to have post-sitemap but not for your CPT. Is this correct?”

Here is a link to a screenshot. In this case, the CPT is called “certificates”.

I want to have the CPT archive in the sitemap, but not the individual posts in the CPT. That does not seem to work even when checking the second box to include the archive in the sitemap.

Thank you!

Yes the CPT has contents – thousands of posts. I have checked the sitemap. If the archive and the single posts are both selected to be indexed, then the archive and the single posts are added to the sitemap. If only the archive is selected to be indexed (and not the single posts), then the archive is not added to the sitemap. That is the problem I am curious about. Why does selecting the archive to be added to the sitemap not work on its own? It seems the archive can only be added to the sitemap if the single posts are also added? That is not how the UI is set up – there is a checkbox in the archive controls that says “Show the archive in search results” … but that seems to only work if the single posts are also added. Is there another solution beyond during the archive into a custom page template and adding it as a page?

Thanks so much, Vladimir! Have a great day.

Thanks for the reply – we have thousands of custom post type posts. Setting them all to noindex isn’t realistic, nor is adding their post ids to a function to remove them from the sitemap.

`Custom Content Type Archives
Note: instead of templates these are the actual titles and meta descriptions for these custom content type archive pages.`

I don’t understand why choosing YES on items in the above listed section does not add those “custom content type archive pages” to the sitemap. Since they aren’t pages, this is the place to add Page Title, Description or to set whether they are put in the sitemap.xml. That is the expected behavior.

Many custom post types have posts that individually aren’t meant to be indexed – shopping sites, review sites.

So how does one add the custom post type archive into the sitemap without the individual posts being added to the sitemap aside from deselecting every single custom post type post?

Thanks!

Thank you @devnihil for the reply.

I’d like to have only the archive for a custom post type get shown in the XML sitemap, but not any of the custom post type posts.

For example, we have 1,285 news clips as posts in a Custom Post Type. Each of those news clips should not be individually indexed or listed in the sitemap. The news clips are never meant to be viewed on their own as a single page. Google should not index them individually as a single page. But the archive page showing all 1,285 news clips should be indexed and included in the sitemap.

This seems to be a common use case, but I can’t seem to achieve the above in the new version 7 settings.

Per the example above, turning ON the “Show the archive for News Clips in search results?” under Custom Content Type Archives does not add the archive page at …/news-clips/ to the XML index. The only way to get the archive page at …/news-clips/ to the XML index is to turn ON the “Show News Clips in search results?” under the “News Clips (news_clips)” which does then display the archive page at /news-clips/ in the XML Sitemap at …/news_clips-sitemap.xml but also shows all 1,285 individual news clips posts (which aren’t meant to be seen) at urls like …/news-clips/news-item-1/

So other than adding a filter function to filter out all the individual posts in a custom post type in order to show the custom post type archive in the XML sitemap, is there another way? I feel like this is a pretty common use case.

Thanks!

• This reply was modified 6 years, 8 months ago by axlright.

Thanks again @galbaras

The pagination links work fine. I’m not able to have Yoast pass the metadata name / value information for:

<link rel="canonical" href="https://website.com/page/3/" />
<link rel="prev" href="https://website.com/page/2/" />
<link rel="next" href="https://website.com/page/4/" />

You’re right, I’m not including code that shows $wp_query->max_num_pages – the pagination works with and without it and including it does not solve the above mentioned issue.

I’ll try your solution. At this point I’m in it just for the stubborn victory.

Is anyone able to get Yoast to include the above metadata on custom loops?

Thanks!

• This reply was modified 7 years, 3 months ago by axlright.

Duplicate comment, sorry. Having trouble with the code separating tick marks.

-Alex

• This reply was modified 7 years, 3 months ago by axlright.
• This reply was modified 7 years, 3 months ago by axlright.

Thanks so much @galbaras – I checked out both of those and implemented multiple variants of the second and did quite a bit more and still no dice. The pagination works fine – using either Reverie’s pagination or basic WordPress pagination. I just can’t get Yoast to show the rel=”next” and rel=”prev” meta elements in the head, nor does rel=”canonical”.

Using a really standard loop like this, Yoast still won’t show rel=”next” and rel=”prev” meta elements in the head, nor does rel=”canonical”

`
<?php
$paged = (get_query_var(‘paged’)) ? get_query_var(‘paged’) : 1;
$args = array(‘posts_per_page’ => 3, ‘paged’ => $paged );
query_posts($args); ?>
<!– the loop –>
<?php if ( have_posts() ) : while (have_posts()) : the_post(); ?>
<!– stuff –>
<?php endwhile; ?>
<?php next_posts_link(); ?>
<?php previous_posts_link(); ?>
<?php else : ?>
<!– Oh no –>
<?php endif; ?>
$the_query = new WP_Query( $args );
?>`

I’ve commented out every non-critical part of both the parent and child functions.php. It works great when using the standard loop – rel=”next” and rel=”prev” and rel=”canonical” does show up properly based on the archive of all blog posts (and the reverie theme’s built in pagination) so I know it can work.

Next up I guess is the ‘pre_get_posts’ route. I Yoast supposed to work this way? If so, maybe I’m fighting an uphill battle.

Thanks!

-Alex

Thanks. Can’t get Yoast to show the rel=”next” and rel=”prev” when declaring $wp_query as global. Here’s the loop contents. The pagination is pulled from the theme’s index.php which does show the rel-“next” and rel=”prev”

<?php
$args = array(
'post_type' => 'photos',
'posts_per_page' => 1,
'paged' => get_query_var('paged') ? get_query_var('paged') : 1
);

global $wp_query;
$wp_query = new WP_Query($args);		
	while ($wp_query->have_posts()) : $wp_query->the_post(); ?>
	 //do stuff			
	<?php endwhile; // End the loop 
	?>
<?php /* Display navigation to next/previous pages when applicable */ ?>
<?php if ( function_exists('reverie_pagination') ) { reverie_pagination(); } else if ( is_paged() ) { ?>
<nav id="post-nav">
	<div class="post-previous"><?php next_posts_link( __( '&larr; Older posts', 'reverie' ) ); ?></div>
	<div class="post-next"><?php previous_posts_link( __( 'Newer posts &rarr;', 'reverie' ) ); ?></div>
</nav>
<?php } ?>
	<?php wp_reset_postdata();?>

• This reply was modified 7 years, 3 months ago by axlright.

Thank you @galbaras – great thinking. I’ll check on that. Really appreciate posting the suggestion.

Thanks @suascat_wp – really helpful. I’d love to find more resources regarding “custom code may need to be written by a developer to pass information between our plugin and the plugin or theme creating the pagination.”

I know that the theme’s pagination works using the pagination function on the “standard” index.php and that the rel=”next” and rel=”prev” does show up properly based on the archive of post-types, but not with a custom ‘$wp_query = new WP_Query($args);’ loop even when using the exact same pagination function from index.php.

I’d be happy to pay for Premium Yoast support if that would be a resource for solving the issue. Or if anyone has tips on passing information between Yoast and the theme for pagination to make rel=”next” and rel=”prev” show up, I’d be super appreciative.

THANKS!

Based on the feedback of @ajoah, this update to line 1774 technically makes the plugin work in PHP7 :

return ${$all_options['first_order']} . ${$all_options['second_order']} . ${$all_options['third_order']} . ${$all_options['fourth_order']} . ${$all_options['fifth_order']} . ${$all_options['first_order']} . $all_options['seventh_order'] . $promote;

One non-fatal error still exists :

Methods with the same name as their class will not be constructors in a future version of PHP; WPRealtimeSitemap has a deprecated constructor in wp-realtime-sitemap/wp-realtime-sitemap.php on line 32

• This reply was modified 7 years, 9 months ago by axlright.
• This reply was modified 7 years, 9 months ago by axlright.
• This reply was modified 7 years, 9 months ago by axlright. Reason: fix typos
• This reply was modified 7 years, 9 months ago by axlright. Reason: fix typos

Thanks. You’re correct. I had assumed that the Custom Post Types themselves had numerical IDs. I took care of finding and excluding all of the posts that were made using the Custom Post Types and that did the trick.

Thank you again for being so responsive.