I have figured out the culprit.
I have a default script added to my functions.php to prevent certain pages from being added to the sitemap:
add_filter(
'the_seo_framework_sitemap_exclude_ids',
function( $ids ) {
$lp_parent_ids = get_posts( [
'post_type' => 'landing_page',
'fields' => 'ids',
'post_parent' => 0,
] );
//$my_exclude_ids = get_posts( [
// 'post_type' => 'post',
// 'fields' => 'ids',
// 'category' => 9
//] );
return array_merge( $ids, $lp_parent_ids, $my_exclude_ids );
}
);
However, the return was throwing an error when $my_exclude_ids is empty (as I commented out the code above it).
I will mark this as resolved.
I’m glad you found the cause!
Some backstory: the sitemap sets a lock when it’s building a cached copy. This prevents it from becoming a denial-of-service attack vector. The lock is released once the sitemap is built, but it cannot be released if the process crashes. The lock is automatically released after 180 seconds or PHP’s max execution time (whichever is smaller).
In any case, if you don’t want the landing_page post type to appear in the sitemap, don’t you also want it to be unindexable? It might then be easier to apply “noindex” to the post type; this will also remove the posts from the sitemap.
Hi @cybr thanks for the explanation.
Regarding the Landing Pages – I generally only want the top level ones hidden from the sitemap, but the children to still be visible, hence the code.
I actually manually mark each top-level Landing Page as noindex too.
