Moving a News Portal to WordPress Without Losing Search Traffic or Google News

You can move a news portal to WordPress without losing your search traffic or your Google News visibility, as long as five things survive the move: every old URL gets a one-step 301 redirect to its new home, every article keeps its original publication date and byline, your structured data and news sitemap keep working, your paywall markup is still correct, and someone watches Search Console daily for the first month. Google says to expect “temporary fluctuation in site ranking during the move”, and that larger sites take longer to settle. So the goal is not zero movement. The goal is a short dip, a clean recovery and no lost archive.

This piece is written for the editor-in-chief, the head of digital or the CTO who has to approve a news portal to WordPress move and live with the result. It covers archives, URL patterns, redirects, NewsArticle markup, the news sitemap, AMP leftovers, author pages and paywalls. Every fact about Google comes from Google’s own documentation, and we say so where something has changed. One of those changes is not what most people still believe, so read the Google News section even if you skip the rest.

Why do news sites lose traffic in a platform move?

They lose it in a handful of boring ways, and none of them are about WordPress.

• Old URLs return errors. A forgotten section, an old tag page, or a 2014 article with a strange URL pattern goes to a 404.
• Redirects point to the wrong place. Thousands of old URLs sent to the homepage tell search engines the content is gone.
• Dates change. The importer stamps every article with the import date, and a ten-year archive suddenly looks brand new.
• Bylines break. Author names turn into plain text, and author pages vanish.
• Markup is lost. The old templates printed structured data. The new ones do not.
• Staging leaks. A noindex tag from the test site goes live, or the live site stays blocked in robots.txt.

Google’s own site-move guide lists the right shape of the job: prepare and test the new site, map old URLs to new ones including images, turn on server-side redirects and check canonical tags, then monitor both sites in Search Console, server logs and analytics (Google: site move with URL changes). Everything below is that list, applied to a newsroom.

Step one: what is in the archive, and what should come across?

Start with a count, not a feeling. For each content type, write down how many items exist, how many get traffic and how many have problems.

• Articles, split by year and section.
• Live blogs, galleries, videos, podcasts and opinion pieces, if they are separate content types.
• Authors, contributors and staff profiles.
• Tags, topics, series and section pages.
• Media: images, captions, credits, embedded video and audio.
• Comments, if you keep them.
• Special pages: about, ethics policy, contact, corrections.

Then split the archive into three piles. Move and redirect: everything that earns traffic or links. Move without ceremony: older material with little traffic that you still want to keep. Retire on purpose: duplicate pages, empty tag pages, old campaign pages. Google’s guide says to return a 404 or 410 for content you are not moving, so a retired page should answer with a clear “gone”, not a redirect to somewhere unrelated.

How big is too big?

A large archive changes how you build, not whether you can move. Hundreds of thousands of articles need batched imports that can resume after a failure, a verified count at the end of each batch, and database indexes on the fields that every list page and export sorts and filters by. The new site’s archive pages, tag pages and admin lists must be paginated, with a real total count, or the portal gets slower on launch day than the old one was. Plan a seeded test with a realistic volume before the editors see anything, because a screen that feels fine with 500 posts can fail with 500,000.

Step two: how do you map URLs so nothing breaks?

News sites carry URL patterns that grew over time. A typical portal has several at once: /2019/04/12/story-slug, /section/story-slug-123456, /node/123456, and an /amp/ version of each. The map must cover all of them.

Build the URL map as a data table with one row per old URL:

Old URL	New URL	Type	Rule
/2019/04/12/story-slug	/story-slug/	Article	Pattern rule
/section/story-slug-123456	/story-slug/	Article	Lookup by old ID
/author/jane-doe	/author/jane-doe/	Author	Pattern rule
/topic/elections	/topic/elections/	Topic	Pattern rule
/old-campaign-page	none	Retired	410 Gone

A few rules from Google’s guide keep the table honest:

• Use permanent server-side redirects, such as 301 or 308. The guide says “301 and other permanent redirects don’t cause a loss in PageRank.”
• Redirect each old URL straight to the final URL. The guide asks you to avoid chains, ideally with no more than three hops and fewer than five.
• Do not send many old URLs to an unrelated page such as the new homepage.
• Include images, video, CSS and JavaScript in the map, not just article pages.
• Keep the redirects “for as long as possible, generally at least 1 year.”

Our own migration process produces a redirect map covering every old URL, validated against the old sitemap and tested before cutover. That detail comes from our WordPress migration page, and the same rule applies whoever does your move.

For a large archive, never type this table by hand. Generate it from the old database, apply pattern rules for the bulk of it, and use a lookup for the oddities. Then test it in bulk: take the old sitemap, your top pages from analytics and a random sample of the long tail, request each old URL against staging and check that it returns one 301 to the expected page.

Should the URL structure change at all? Usually not, for the first release. If the old URL ends with the slug and a date, and WordPress can reproduce it with a permalink setting, keep it. A move that changes the platform and the URLs at once doubles the things that can go wrong. Change structure later, in a second, separate project.

Step three: keep dates, bylines and authors intact

News is the one kind of content where the date is part of the product. Google’s best practices for article pages ask for a “clear, visible date and time”, ideally between the headline and the article text, and they say not to artificially freshen stories. A new date should appear only when the article has been substantially changed (Google: best practices for article pages).

For a migration, that means:

• The importer writes the original publication date, with its time zone, into WordPress. It never uses the import time.
• The last-modified date comes from the editorial record, not from the import.
• Scheduled articles keep their scheduled time, and the importer does not publish them early.
• Time zones are stored once and shown one way everywhere.

Authors and author pages

Google’s article markup guidance says author.url should be “a link to a web page that uniquely identifies the author”, for example a bio page or a social profile. It also says to list each author in a separate author entry and to include every author shown on the page (Google: Article structured data).

So author pages are not decoration. Decide early:

• Which authors become real WordPress users with logins, which become author profiles only, and which become archived profiles for people who left.
• How guest contributors and wire-service credits are stored, so a byline like “Staff” or “Agency” does not point at one unlucky account.
• That each author has a stable URL, a bio and a list of their stories, and that the old author URLs redirect to it.

Step four: what happens to Google News and Top Stories?

Many newsroom teams still believe two things that are out of date: that you must register the site in Publisher Center to appear in Google News, and that AMP is needed for Top Stories. Google’s documentation says otherwise on both.

Publisher Center

Google’s help page on the change says that Google News moved to automatically generated publication pages in late March 2025, and that “Google News will no longer use RSS feeds or web locations that were submitted in Publisher Center”. It also says content eligibility is unchanged: content that follows Google’s content policies is automatically considered for Google News and other news surfaces (Google: Google News transitions to automatically-generated publication pages).

Another Publisher Center help page says Google’s systems algorithmically discover news content, that publishers do not need to submit their site, and that inclusion is not guaranteed (Google: help Google News discover your content).

What this means for a move: there is no registration step to redo on the new platform. What you must keep is the content itself, the basics Google’s policies expect (clear dates, bylines, and information about the publisher and contact details), and crawlable pages. We did not find a Google page that says a platform change by itself affects eligibility. What it can affect is whether the pages stay crawlable, correctly dated and consistent, which is why those items get the most care.

The news sitemap

A news sitemap tells Google about your new articles. Google’s documentation gives the rules (Google: news sitemap):

• You can add news tags to an existing sitemap or create a separate news-only sitemap. A separate one may make tracking in Search Console easier.
• Each entry needs the publication name, a language code, the publication date in W3C format and the article title as it appears on your site.
• The publication name must exactly match the name on news.google.com, without anything in parentheses.
• The date is the original first-publication date and time, not when the URL was added to the sitemap.
• A sitemap can hold up to 1,000 tags.
• Only include recent URLs: “articles that were created in the last two days.”
• Update the same sitemap as articles are published, and do not create a new sitemap with each update.

Three practical points for the move. First, the news sitemap must be live and fresh on the new site on cutover day, so build it and test it on staging. Second, do not fill it with the whole archive, because the two-day rule exists for a reason. Third, the sitemap may be empty for a while during a quiet period, and Google says an Empty Sitemap warning in Search Console does not cause problems for Search.

AMP leftovers

If your old portal ran AMP, you now have a second set of URLs to think about, usually ending in /amp/ or ?amp. Here is what Google’s documentation says. Google first announced in 2020 that it would remove the AMP requirement from Top Stories eligibility. A later Search Central post said any page meeting Google News policies is eligible for the Top Stories carousel. Google’s documentation updates log for July 1, 2026 says Search now sends users directly to publishers’ AMP host pages, publishers no longer need to maintain the AMP Cache or set up signed exchanges, and AMP pages continue to rank like any other web page (Google Search documentation updates).

So AMP is not a reason to stay on an old platform, and it is not required on the new one. Our recommendation, which is ours and not Google’s: do not rebuild AMP on WordPress. Add every AMP URL to the URL map, and redirect each one with a 301 to the matching normal article page. Then check Search Console for the old AMP URLs a few weeks later. If you do decide to keep AMP, keep the markup and the paywall rules the same on both versions, which Google’s paywall page asks for.

Step five: recreate NewsArticle markup and checks

Google supports three schema.org types for article markup: Article, NewsArticle and BlogPosting. Google also says no properties are required, and recommends author, author.name, author.url, dateModified, datePublished, headline and image. It recommends including time zone information in the dates, and adds that without it Google defaults to the time zone Googlebot uses.

Google’s article-page best practices add a few more rules a news template should follow:

• Keep the headline in structured data to 110 characters or fewer.
• Specify only images that directly belong to the article.
• Put the title in a prominent spot above the body, in an h1 tag, and match the HTML title tag to the h1.
• Do not put a date or time in the title.
• Make every page reachable from at least one static text link.

In WordPress, markup is generated by the theme or an SEO plugin, so the work is to pick one source of truth and test it. Do not run two plugins that both print NewsArticle JSON-LD, because duplicate and conflicting markup is a common result of a rushed build. The test list:

1. Pick ten articles of different kinds: a short brief, a long feature, a live blog, a gallery, an opinion piece, a paywalled piece.
2. Run each through Google’s Rich Results Test on staging.
3. Compare the markup with the old site for the same article. Dates, headline, image, author and publisher should match.
4. Check the HTML title against the h1.
5. Repeat for one article from each of the oldest years of the archive, since old content often has odd field values.

Step six: how do you protect a paywall or a meter?

A paywall changes what search engines see, and Google asks publishers to say so in markup. Google’s paywalled-content page says to use schema.org CreativeWork markup with isAccessibleForFree set to false, plus hasPart and cssSelector to point at the paywalled section. It says to use .class selectors only and not to nest sections. It says the markup helps Google tell a paywall from cloaking, which violates spam policies, and it recommends making sure Googlebot and Googlebot-News can access your pages (Google: paywalled content structured data).

On a move, the risks are practical:

• The new paywall template wraps the locked section in a different class, and the markup still names the old one.
• The metered or registration wall hides content from crawlers in a way the old one did not.
• A bot access rule is different between the normal and AMP versions of a page.

Google’s paywall page links to separate guidance on flexible sampling. We did not read that guidance for this article, and the paywall page itself does not explain metering strategies, so if you run a meter, check Google’s flexible sampling documentation directly before you finalise the design.

Our media and publishing page says we build metered, hard, soft and registration-wall hybrid paywalls with Stripe billing, and that we work with household sharing, gift subscriptions and group accounts. Whatever you choose, treat subscriber accounts as a separate stream of work with its own privacy review and test plan. Active subscriptions and payment methods must move or be re-linked with the payment provider, and subscribers must be told in advance.

Step seven: editorial workflow, ads and speed

Search traffic is the thing most editors worry about, but the newsroom will notice other things first.

• Workflow. Map the states your editors use today: draft, in review, legal check, scheduled, published, corrected. Our page says WordPress can carry custom edit queues, fact-check stages, legal review, embargo schedules and embargo-aware preview links.
• Corrections. Keep the correction note and the date it was made. A corrected article should show its updated time honestly, which Google’s date guidance supports, and not look freshly published.
• Ad stack. Ad tags, header bidding and consent tools must be rebuilt and tested on the new templates, including lazy loading, since ads are a common cause of slow pages and layout shifts.
• Speed. Test Core Web Vitals on staging with the real ad stack turned on, not with ads off. Google’s documentation says page experience is not an eligibility requirement for Top Stories, but a slow portal still loses readers.
• Newsletters. Sign-up forms and the subscriber list sync need to work on day one.

Step eight: staging, rehearsal and cutover

Stage the new site on a private address and keep it out of search with a proper block. Then work through the pre-launch list.

1. Confirm robots.txt and any noindex rules are right for the live site, and that no staging block is left in place. Google’s guide lists this as step one.
2. Run the full URL map against staging and check every response code.
3. Compare article counts by type and year, source against destination.
4. Compare the top 200 pages by traffic, visually and in markup.
5. Test publishing, scheduling, editing and unpublishing as an editor.
6. Test the news sitemap, the main sitemap and the paywall markup.
7. Rehearse the cutover and the rollback with a clock running.

Our service page describes a staged cutover in a low-traffic window, followed by 30 days of Search Console, Core Web Vitals and error log monitoring, and our media page says migrations are done section by section while live publishing continues. The news calendar matters here. Do not cut over in the middle of an election night, a budget day or the week of your biggest annual event. A quiet Tuesday morning beats a busy Friday evening.

Delta sync

Your newsroom keeps publishing during the build. A delta sync copies only the articles added or changed since the last import, and it runs once more immediately before the switch. For a breaking-news site, plan for a short window where editors publish on the old site only, then the final delta runs, then everyone moves to the new site. Tell the team the exact minute.

Step nine: what do you watch after launch?

Google says you must verify both the old and new sites in Search Console, and notes that for a domain or subdomain change you submit a Change of Address for the old property. It says you do not need that for an HTTP to HTTPS move or a change to or from www. It also says Googlebot needs to visit every old and new URL at least once for a move to be considered complete.

For the first month, check daily:

• Search Console coverage. New errors, 404 spikes and “Crawled, currently not indexed” growth.
• Search Console performance. Impressions and clicks for your top sections, compared with the same weekdays before the move.
• News sitemap status. Is it being read, and are new articles appearing?
• Server logs. Which old URLs are still being requested, and do any return a 404 or a chain?
• Analytics. Organic landing pages, with a list of the top 200 compared against the prior month.
• Core Web Vitals. Field data takes time to appear, so check lab results too.

Treat any unexpected 404 for an old URL with traffic as an urgent fix, and add the pattern to the map so the same kind of URL never fails twice. Keep the redirects for at least a year, as Google advises, and longer for URLs that still earn links.

A pre-launch checklist for the editor-in-chief

Print this and hold the technical team to it.

1. We have a signed-off count of every content type, old against new.
2. Every old URL, including AMP and image URLs, appears in the map with a rule.
3. Redirects are single-step 301s, tested in bulk, with no chains.
4. Publication dates and authors match the old site on a sample of 200 articles across every year.
5. NewsArticle markup matches the old markup on ten article types.
6. The news sitemap is live on staging and updates when an article is published.
7. Paywall markup names the right class, and crawlers can reach the pages.
8. robots.txt and noindex are correct for the live site.
9. Editors have published, scheduled and corrected an article on staging.
10. The cutover window avoids the biggest news event of the quarter.
11. The rollback has been rehearsed.
12. Someone owns Search Console for the first 30 days.

Questions people ask

Will moving a news portal to WordPress hurt my Google News visibility?

Google’s documentation says content that follows its content policies is automatically considered for Google News, and that eligibility does not depend on submitting your site. We found no Google page saying a platform change affects eligibility. The risk is in the details: crawlable pages, correct dates and bylines, and working redirects.

Do I need to resubmit my site to Publisher Center?

Google says submitted RSS feeds and web locations in Publisher Center are no longer used by Google News, and that publishers do not need to submit their site to be considered. Check Google’s current help page before relying on any older instructions.

Do I still need AMP to appear in Top Stories?

No. Google removed the AMP requirement from Top Stories eligibility, and its July 2026 documentation update says AMP pages continue to rank like any other page. Redirect old AMP URLs to the normal article pages unless you have a reason to keep AMP.

How long should I keep the redirects?

Google says to keep them for as long as possible, generally at least one year.

How long until traffic settles?

Google says to expect temporary fluctuation and that larger sites take longer than small and medium ones. It gives no fixed number of days, and we will not invent one. Track the same weekdays before and after, and fix what the data shows.

Can we keep publishing during the move?

Yes. That is what the staged build and the delta sync are for. Editors keep working on the old site until the final sync, then switch together.

The next step

If you run a news portal and a move is on your mind, the best first step is an audit of your archive and URL patterns, because that tells you the real size of the job and where the risk sits. Our media and publishing page shows how we work with publishers, and our WordPress migration service describes the audit, staging and monitoring phases. Tell us about your archive size, your paywall and your ad stack, and we will tell you honestly what a safe move looks like. If your archive also needs a larger consolidation, our headless CMS platforms comparison covers the other routes.