SEO stands for search engine optimization. It's a way of optimizing data on your website so that the search engines can recognize it and drive organic traffic to it.

Even though we are using Yoast SEO plugin to handle most of the SEO-relevant metrics (from content analysis to meta tags, and structured data), there are some things that we need to make sure are set on the website before releasing it live.

We have two scenarios we'll have to cover:

1. a new website without prior existence on the Internet
2. an existing website that we need to migrate and regain or improve their existing search ranking.

New website

When we are creating a new website, we need to make sure that the client is aware of how the content is structured on the website. Some of the most important things to be aware of are

• Having different heading sizes in the correct order (H1 -> H2 -> H3 -> H4)
• No more than one H1 tag
• Images in the content with set alt tags
• Enough inbound and outbound links
• Set meta descriptions
• Images shouldn't be too large
• Set the Open Graph images (OG) for the page/post

Don't use SVGs for featured images or OG images, as they won't be rendered on social networks and in search results

Yoast SEO plugin will warn if these are not properly set, but it's good to have them in mind nonetheless.

Make sure content editors are aware not to put too large images. Anything over 200 KB is considered large by Google Lighthouse and will be counted as a penalty when calculating a page score.

Besides content, the client should set proper meta descriptions for every page and post, keywords for posts, and social images (OG images). All of these can be set from the Yoast meta box at the bottom of the post/page.

Developer notes

Developers should make sure that a correct permalink structure is set (Settings / Permalink Settings - post name), and that all Yoast settings are correctly set up (organization images, social details, Google verification code, etc.).

By default, WordPress will generate a robots.txt file that will instruct crawlers which pages should be crawled. You should add the sitemap.xml file to the robots.txt list as well. You can do that by adding robots.txt file in root directory of the site.

File should look like this (Replace YOUR-SITE.URL with the actual URL of your site).

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://YOUR-SITE.URL/sitemap_index.xml

Alternatively, you can add this code snippet in case you don't have access to the server files or permissions for editing them:

<?php

/**
 * The file that holds the SeoFunctionality class.
 *
 * @package ProjectNamespace\Seo;
 */

declare(strict_types=1);

namespace ProjectNamespace\Seo;

use ProjectNamespaceVendor\EightshiftLibs\Services\ServiceInterface;

/**
 * SeoFunctionality class.
 */
class SeoFunctionality implements ServiceInterface

{

    /**
     * Register all the hooks
     *
     * @return void
     */

    public function register(): void

    {
        \add_filter('robots_txt', [$this, 'robotsFilter'], 100, 2);
    }

    /**
     * Robots txt modification
     *
     * Add the sitemap to the robots.
     *
     * @param string $output The robots.txt output.
     * @param bool $public Whether the site is considered "public".
     *
     * @return string Modified output of the robots.txt file.
     */

    public function robotsFilter(string $output, bool $public): string
    {
        $homeUrl = get_home_url();

        $output .= "Sitemap: {$homeUrl}/sitemap_index.xml\n";

        return $output;
    }

}

Both of these methods will add the sitemap to the robots file. The sitemap is generated by the Yoast plugin and is a crucial way to tell search engine crawlers which pages should be crawled.

Some pages, like search result pages and Thank you pages (form submissions Thank you pages), shouldn't be indexed. Yoast and WordPress should add the necessary <meta name="robots" content="noindex, follow"> tag that won't index search result pages. But make sure it's there when testing the site.

When creating custom post types, check if they will be of a specific type. By that, we mean things like FAQ posts, recipes, events, products, etc. because they should have specific structured data associated with them.

Basic checklist

Before deploying to production make sure to check that:

• Posts and pages have correct OG images set
• Remove noindex option (blocking search engines from the WordPress settings)
• Check if canonical links are set correctly
• Check if the domains are consolidated (work with DevOps engineers on this one)
  • http to https redirection is set
  • correct www version is set (site should either have www or not, and redirections should be set)
  • Trailing slashes - choose either with or without it
• Check that sitemap doesn't have 301 links in it
• Optimize images, especially on the main pages

In the case, the site was on another domain and a new one is being set up it's crucial to check the redirections and if they are correct. For redirections, we are using the Redirection plugin.

Once we check for the errors using automated tools (Lighthouse, Screaming Frog, Ahrefs, Semrush) we should fix those and resubmit the new sitemap.xml in Google Search Console (so it can be reindexed).

The existing website (content migration)

We won't be covering the content migration itself here, as that is covered in the other chapter of the handbook.

Here we'll cover things that developers need to be careful about when doing the migration.

Before doing the migration we should work with the Growth team in detail so that they can get all the relevant information about the existing site.

They will give us information about the site's health (number of dead links, existing SEO ranking, top 50 pages/posts on the old website, etc.)

When migrating the content it's crucial to get all the old links from the website associated with the new website. That means that the old permalink should be added to the migration data, as well as some extra identifiers such as old post ID, and stored as metadata for every imported post.

This will allow us to easily fetch all the new and old permalinks that we can easily add to the redirect list. Also, it would be good that the old permalinks that had the biggest SEO score on the old website remain the same on the new one if possible (if not, prioritize that their redirects are set up correctly).

Given the size of the old website and the new website, we can list old links by hand. Note that if you had a huge number of posts, this won't be workable (which is where storing these data as metadata becomes useful).

Information architecture should also be taken into account. If the previous website had a good information architecture, we should strive to keep it. If the information architecture was bad (no content separation, too many tags on one article, lack of categorization), we should work with designers to improve it.

It is vital to have a good information architecture so that the users can find the information on the site quickly, and also that the related information is well connected. That way we can keep the user on the site for a longer period of time. If that is the intention of the site of course - some sites are presentational and should convey the information in a clear way. In that case, the bounce rate can be high, but then the site visits will also be high.

We should run the same checklist as in the case of a new website, but we should take more care at the following:

Once the content is migrated, we should check the redirect links immediately. Using automated tools we should fix all the redirections that are duplicated, or broken.

We should also be mindful not to create redirect chains and loops unintentionally.

For instance, using the automated process we imported 40k redirect links. In this list, we have a redirection from URL A to URL B (we are not aware of this, as it's a huge list).

Later, using manual tools, we found out that we should redirect URL B to some other URL C.

With that we have created a redirect chain, because now when a user goes to link A, they will be redirected to link C, but via link B. This redirection should go from A to C directly.

We should then remove the first redirection and replace it with a direct one. The redirect chains can be detected by automated tools from the Growth team.

Once we fix redirects, we should make sure that the canonical links are set correctly. This should be handled by WordPress.

Broken links should be fixed, because they will impact the credibility of the brand, but also because they will impact the backlinks. Backlinks provide the domain authority of the website, so broken backlinks would impact the SEO.

Once we fixed all that we should wait a few days to check the new data from the Search Console, and act accordingly.

Blocks

Our blocks are SEO-ready out of the box with the Yoast plugin. Since we are using dynamic blocks, we created a helper that will parse the content and pass it using JavaScript to Yoast so that it performs the correct SEO analysis.

For more information check the blocks documentation.