Migrating a media outlet to another platform is scary, and rightly so. Behind every URL there are years of links, Google rankings and traffic that is hard to earn and easy to lose. A badly done migration can erase in weeks what took years to build. A well-done one goes almost unnoticed by the reader and by Google.
This is the guide we would follow to move an outlet from WordPress to Arc XP. It starts from one idea: migrating is moving traffic, not just content. If you want to know first whether the jump suits you, read Arc XP vs WordPress for a digital media outlet.
Your archive is an SEO asset. Every URL that ranks must make it to the other side, either unchanged or with a well-placed 301 redirect.
1. Inventory: what you have and what ranks
Before touching anything, do a complete inventory.
- Content: articles, galleries, videos, pages, authors, categories and tags.
- Performance: export from Search Console and your analytics the URLs with the most clicks, impressions and inbound links.
- Particularities: shortcodes, embeds, custom fields and plugins that generate content.
With that list you decide what is migrated as is, what is cleaned up and what is dropped. Not the whole archive deserves the trip.
2. Content model: from WordPress to ANS
Arc XP stores content in its own format, ANS (Arc Native Specification). Each WordPress content type has to be mapped to its Arc equivalent: articles, images, galleries, authors and sections. The key questions:
- How are shortcodes and editor blocks converted? They usually need transformation rules.
- What happens to categories and tags? They are normally related to Arc's sections and taxonomy.
- Where do custom fields live? Some become content model fields and others are dropped.
This mapping is the most important work: it defines how much of your archive arrives clean.
3. Migrating content and images
Content is not copied by hand. You write a migration process that reads from WordPress (its API or an export), transforms each piece to Arc's format and ingests it through the platform's APIs. Some rules that save you scares:
- Migrate a small sample first and review it by eye before launching the full archive.
- Make the process repeatable: you will have to run it several times until it comes out clean.
- Treat images separately: download, optimize, upload and rewrite the references in the article body.
- Keep publication dates and bylines: they are part of what Google and the reader expect to see.
4. URLs and 301 redirects
This is the part that decides your SEO. The rule is simple: if you can keep the URL, keep the URL. When you cannot, each old URL must answer with a 301 redirect to its new equivalent.
Case | What to do |
|---|---|
The URL can stay the same | Keep it: it is ideal |
The structure changes | Old-to-new URL map, with one-to-one 301s |
Content that is dropped | 301 to the closest section, or 410 if there is no equivalent |
Images, feeds and author pages | Review them too: they receive traffic and links |
Pagination and URLs with parameters | Define a canonical and redirect criterion |
Test the full map in a staging environment with a list of thousands of real URLs, not ten examples. A 404 that shows up here is a 404 you will not see in production.
5. Technical SEO that must survive
- Titles, meta descriptions and canonical for each piece.
- Structured data (for example, NewsArticle), sitemaps and, if you use it, the news sitemap.
- hreflang tags if you have editions by language or country.
- Performance: a new front end on Arc must meet your Core Web Vitals, not worsen them.
- robots.txt and noindex tags: the test environment must not be indexed, and production must be.
6. The cutover and the first weeks
On cutover day: briefly freeze editing, run the last incremental migration, enable the redirects and point the domain. Afterwards, watch:
- Search Console: coverage, crawl errors and new 404s, daily during the first week.
- Rankings of your 50 most important URLs and organic traffic by section.
- Server logs, to see which old URLs bots still request and that none is left without a redirect.
A small fluctuation is normal while Google reprocesses. A sharp and sustained drop almost always points to missing redirects or a slower front end.
The dress rehearsal almost nobody does
Two weeks before the cutover, run the full migration in a staging environment and treat it as if it were the real day. Take a sample of 200 URLs that rank and compare each one: response code, canonical, title, H1 and images. Check that every redirect is a single hop, with no chains, and that none ends in a 404.
Rehearse the way back too: being able to revert DNS in minutes is what lets you cut over calmly. If the rehearsal fails, the cutover date moves, not the standard. Migrations that lose rankings rarely fail because of the technique of the move; they fail because of a weak inventory and a URL map nobody tested with real data.
At Codegea we do migrations to Arc XP taking care of URLs, content and rankings. If you are about to take the step, tell us your case and we will build the plan with you.
Written by
Derian Pinto
Founder & Full Stack Developer
Founder of Codegea. Builds custom websites, stores and platforms, and integrates and supports Arc XP for media companies.