Yoast

Yoast: Considerations for SEO and Backend Management

When creating a custom post type in WordPress, it’s essential to define its purpose and how it should interact with SEO and user navigation. Here’s a breakdown of our typical workflow and best practices for handling post types that don’t require indexing or have no single views.

Deciding Sitemap and Single View Inclusion

Exclude from Sitemap: For post types that you don’t want Google to index, disable their inclusion in the sitemap. This is usually managed through the Yoast SEO plugin:

• Navigate to Yoast SEO > Settings.
• Find the post type in question under the appropriate tab (e.g., Content Types).
• Set “Show in search results” to No.
• Set “Enable SEO controls and assessments” to No.
• Save changes.

After doing this, the Yoast SEO settings for the post type will no longer appear when editing individual posts. This is expected behavior, as we’ve explicitly instructed Yoast to treat this post type as non-indexable.

Hiding Preview and View Buttons in the Backend

For post types that don’t have a single view or are excluded from tracking, it’s often helpful to hide the Preview and View buttons in the WordPress admin. This avoids confusion for users who might think these options are functional.

Here’s how to hide these buttons programmatically:

if(isset($_GET['post'])){
    if(get_post_type($_GET['post']) == 'partner'){
        function hidePreviewButtonSaAdmin() {
            echo '<style>
                .block-editor-post-preview__button-toggle{
                    display:none !important;
                }
                .preview.button{
                    display:none !important;
                }
            }
            </style>';
        }
        add_action('admin_head', 'hidePreviewButtonSaAdmin');
    }
}

This ensures that the buttons are visually removed for the specified post type.

Redirecting Post Type URLs

For post types that don’t have their own single view, you can programmatically redirect their URLs to a specific destination. This ensures that users who try to access the post type’s single pages are directed to a meaningful URL.

Use the following snippet in your theme or plugin:

function redirect_config()
 {
    $queried_post_type = get_query_var('post_type');
    $queried_id = get_queried_object_id();
    $queried_post = get_post($queried_id);

    if (is_single() && 'transaction' == $queried_post_type) {
        $principalUrl = esc_url(home_url('/'));
        wp_redirect($principalUrl, 301);
        exit;
    }
 }
 add_action('template_redirect', 'redirect_config');

Example Use Case:

If the post type is a custom taxonomy that doesn’t require individual pages (e.g., FAQs or Events), redirecting users to a central archive or landing page improves user experience and prevents orphaned URLs. We tend to do it in two different ways.

1. When we’re using projects in Vite we can register the CPT using classes. There, we can set an argument to hide the preview button in the edito (true or false):

'terra_hide_preview_button' => true,

2. If we still have a project in Webpack, we have a custom function to do this:

Custom OG Image Function in WordPress

In our project, we have implemented a custom function that dynamically sets the Open Graph (OG) image for social media previews. The OG image is usually set to the featured image of a page or post. However, we allow for an override of this default behavior by configuring a custom image in the General Options or Theme Options.

Custom OG Image Logic

By default, the OG image is pulled from the featured image of a post or page. However, if a specific image is defined in the General Options or Theme Options for the website, it will override the featured image and be used as the OG image for social media previews.

This functionality is useful for ensuring that certain pages or posts have a specific image for social media sharing, regardless of the featured image set on the page.

Handling Post Types Without an OG Image

If you have a custom post type that does not need an OG image, you can prevent the default OG image behavior by overriding the custom function responsible for setting the OG image.

For example, to disable OG image handling for a particular post type, you can add a conditional check inside the custom OG image function:

function yoast_change_image($image)
{

    if (is_page_template('page-media-kit.php')) {
        $FTmeta = get_the_post_thumbnail_url(get_the_ID(), 'large');
        $my_image_url = $FTmeta;
        return $my_image_url;
    } else {
        $OGmeta = get_field('og_image', 'option');
        $my_image_url = $OGmeta;
        return $my_image_url;
    }
}
add_filter('wpseo_opengraph_image', 'yoast_change_image', 10, 1);

This will prevent the custom function from applying the OG image logic to the specified post type.

Importance of the Featured Image

Another important consideration is that no page can exist without a featured image. In our setup, if a page or post does not have a featured image, there will be no OG image to rewrite, which means the function will not have any image to replace.

If the featured image is missing, the system will not assign any OG image because there is nothing to rewrite. Therefore, it’s crucial to ensure every page or post has a featured image if you want to control the OG image behavior.

By managing the OG image logic this way, we ensure that all content has a consistent and optimized social media preview, while also allowing flexibility for specific content types.