Comparing Yoast Sitemap Settings Before and After Site Migration

When you move a WordPress site or switch SEO plugins, Yoast SEO may create a different sitemap, an XML file that lists URLs for search engines to find. If the move changes the domain or URL structure, the sitemap should list the URLs for the new site. To check the result, confirm that the new sitemap lists the intended URLs that search engines can index and reflects planned changes.

Yoast builds a sitemap index that links to separate sitemap files for eligible content, such as posts, pages, and taxonomies. Compare the old and new settings as well as the URLs in those files. A sitemap that loads successfully does not prove that its contents stayed correct, or that Google will index every listed URL.

Record the old settings and sitemap output

Before the move, note the Yoast SEO version and save the sitemap index and every child sitemap it links to. The current Yoast settings place the sitemap toggle under Yoast SEO → Settings → Site features → Technical SEO; interface labels can vary by version. The Yoast sitemap documentation describes the index and the role of the feature setting.

Record the settings that determine which URLs Yoast includes. In particular, check whether each post type and taxonomy is set to appear in search results. Yoast uses those settings to determine sitemap inclusion. Review standard content, including posts and pages, as well as products and custom post types. Check taxonomies too, including categories, tags, and custom taxonomies. The sitemap customization guidance also describes developer filters that can exclude post types or taxonomies and change how many entries appear in each sitemap.

A canonical URL is the address a site identifies as the preferred version of a page. Yoast’s sitemap functional specification says the sitemap excludes, among other cases, pages set to noindex, private or password-protected pages, and pages with a manually set canonical that differs from the default. Check these rules when a page is missing. For author archives, disabling the archives removes the author sitemap; excluding an individual author does not remove that author’s posts from other sitemaps, according to Yoast’s author sitemap guidance.

Also identify which software serves each sitemap endpoint. Yoast recommends enabling its sitemap feature and says doing so disables WordPress’s default sitemap. Disabling Yoast’s feature, however, does not disable WordPress core’s sitemap. Check the actual endpoints rather than inferring the generator from a URL’s name; Yoast explains this distinction in its site features documentation.

Treat imported settings as a starting point

Yoast lets you export and import settings, including data from other SEO plugins. The import can carry settings to the new site, but it does not confirm that the new site uses the same sitemap rules, customizations, or behavior as the old plugin. Yoast’s import and export instructions describe the tools. Inspect the new sitemap after importing.

Metadata such as page titles and descriptions does not prove that sitemap inclusion rules transferred. Recheck custom post types, taxonomies, individual exclusions, canonical settings, and code filters on the destination site. If the site’s architecture changed, confirm that new or renamed content types have the intended search-results settings as well.

Map planned URL changes before comparing

For a domain or URL-structure migration, create a mapping from each old URL to its intended destination. Google recommends mapping old URLs, updating internal links and canonical annotations, testing redirects, and preparing a sitemap with the new URLs in its site-move guidance.

Keep the URL map separate from the settings record. If the migration changes a URL, the mapped destination should reflect that change. Investigate any URL that still uses the old domain, a staging host, or an unintended path. A different URL count alone does not show that the migration failed. The site may have added, removed, or reorganized content.

Compare the old and new URL sets

Fetch the old sitemap index and open every child-sitemap link it lists. Do the same on the destination site. Parse the XML and extract each <loc> value, which contains a URL. Compare the URL sets instead of the raw XML files. The order of URLs and the division into child files can change even when the set of URLs stays the same.

Use the URL mapping to classify each difference as a planned URL change, a planned addition or removal, an unexpected missing URL, an unexpected new URL, or a URL on the wrong host or path. Also compare which child sitemaps appear in each index. A missing or newly added child file can reveal a changed post type, taxonomy, archive, or integration even if a few sampled pages look correct.

For each high-priority mismatch, check the live page’s HTTP response and redirect destination. Then review its canonical URL and indexability settings. The final URL should match the migration plan and the page’s canonical should identify the intended preferred URL. Google’s guidance on URL canonicalization explains how canonical signals help search engines choose among duplicate or similar URLs.

Check the new sitemap and its limits

Confirm that the sitemap index loads and each child link resolves. Check that the XML parses without errors. Check that every <loc> is an absolute URL on the intended host and uses the expected protocol and path. Make sure no sitemap lists staging or legacy URLs. Also confirm that important content types and taxonomies have child sitemaps when the site intends to include them.

Google’s sitemap guidelines set a limit of 50,000 URLs or 50 MB uncompressed for each sitemap file. Yoast documents a default of 1,000 entries per sitemap, so it may create more child files. Custom code can change this default. Google’s limit applies to the sitemap format; compare Yoast’s actual output with the site’s recorded settings. Google uses sitemap URLs to discover pages and understand canonical URLs, but listing a URL does not guarantee that Google will crawl or index it. See Google’s sitemap guidance.

After submission, use Search Console to monitor the sitemap and investigate reported issues. A successful submission or fetch does not prove that Google crawled every URL or selected the intended canonical. Search Console data complements the direct XML and page checks; it does not replace them.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com