Migrating editorial content: protecting SEO during a migration

Pages, articles, metadata, internal links: migrating editorial content decides what Google will find on the new site. The pitfalls, the priorities, and why to do it before the redirect plan.

Migrating editorial content: protecting SEO during a migration

On an editorial or corporate site or a blog, the content is what Google has indexed and ranked. Migrating it means moving pages and articles to the new site without damaging what earns them their visibility: the text, its structure, its metadata and its links.

This article covers what is specific to content. The general method is in our article on data migration in a redesign; online shops are covered in the one on e-commerce data migration.

Formatting and structure

The first obstacle is layout. Content built with a page builder (Divi, Elementor) or full of shortcodes cannot be read as-is in another editor: moving from Divi to Gutenberg, or from WordPress to another CMS, means converting every block. Check that the heading hierarchy (one H1, then H2s and H3s) survives the conversion: it structures the content for Google as much as for the reader.

When the new template splits content differently (a standfirst, boxes, tabs), migration can no longer be a simple copy and paste: plan splitting rules, or migrate by hand the pages that deserve it.

SEO metadata

Migrate, page by page, what does not show but matters: the title tag, the meta description, image alt text, canonical tags, structured data and indexing directives (a noindex page must stay noindex). These fields often live in an SEO plugin of the old CMS (Yoast, Rank Math) and are not exported with the content: it is the first thing a migration forgets.

Media

Images and documents must follow, with their paths if they are indexed in Google Images or cited by other sites. If their addresses change, they are redirected like pages; see our article on redirecting images.

Internal links

Links from a piece of content to the site's other pages point to the old addresses. If they are not rewritten, every click goes through a redirect, and so does Google: internal linking weakens and redirect chains multiply. Rewrite the links to the new URLs during the migration, using the redirect plan.

Duplicate content

A migration can create duplicates: the same page under two addresses, a print version, a forgotten test page, two merged articles one of which stays online. Spot them during checks and handle them with a redirect or a canonical tag; see our article on checking for duplicate content.

Prioritising content

When part of the migration is done by hand, not everything can get the same care. Start with the content that has value: pages that receive backlinks, traffic or Search Console impressions, and those that generate leads or revenue. In Swan, URLs imported from Search Console, Ahrefs, Majestic or your logs carry their origin: they point to the pages to migrate first. See also the importance of backlinks in a migration.

Migrate before you redirect

For each old page, Swan suggests the page of the new site that replaces it, by comparing their content by semantic proximity. That comparison only makes sense if the content has been migrated to staging: start the migration as early as possible, before both sites are crawled. Our article on semantic analysis before a migration explains this matching, and the redirect plan guide what comes next.

Content migrated to staging? Swan matches each old page with the new one and prepares your redirects.

Read next

All posts