How to migrate an online community to a new platform without losing SEO

To migrate an online community without losing SEO, build a URL map before anything moves, send every old thread to its matching new thread with a single permanent 301, and keep the old addresses answering those redirects for at least a year. Carry over accepted answers, authors and dates, give the new pages self-referencing canonicals, submit the new sitemap, and watch Search Console for weeks.

That's the whole answer. The rest of this post is the order I'd do it in and the places it usually goes wrong.

Most of what a community earns in search sits in old threads. A question someone answered three years ago can still bring in visits every week, and threads like that are exactly the kind of page AI answers draw on when someone asks about your product (more on that in our AI search optimization guide). A platform move can put all of it at risk in a single afternoon, usually because the redirects were treated as a launch-week chore.

Our team moves communities onto Bettermode as a migration add-on (Webflow's community came over from Discourse this year), and I've spent a good part of this year cleaning up redirects on our own site. Here's what I'd tell anyone planning a move.

What a community migration can break

Four things carry your search value, and a careless move can break any of them:

• Thread URLs, and the links pointing at them from docs, blog posts, Stack Overflow answers, your own help center and years of support emails.
• Accepted answers. The marked solution is why a thread is worth landing on, so a thread that loses its marker keeps the page and loses the point.
• Member identity: author names, profiles and their history, plus the accounts people log in with.
• The internal link graph. Members link threads to other threads constantly, and those links hold the archive together.

Rankings will move around for a while even if you get all four right. Google's own site move guidance says to expect temporary fluctuation and that on a medium-sized site it can take a few weeks or more before Google shows the new URLs in place of the old ones. That dip is the cost of moving. Losing the threads is avoidable.

Build the URL map before you pick a cutover date

The URL map is a spreadsheet with one row per old URL and a column for where it goes. Everything else in this guide hangs off it, and Google's guide starts in the same place: prepare a mapping from the current URLs to the new ones. Don't let anyone set a launch date until the map exists.

Pull every URL that has earned something

Combine every source you have: the old platform's sitemap, a Search Console export of every page with impressions, landing pages from your analytics, and a backlink tool's list of pages with referring domains. Add the platform's own export if it has one. Discourse, for example, lets admins download a full backup from the browser.

Dedupe, then sort by clicks and by linking domains. That ranking tells you which rows to check by hand. Map every row anyway, because once you've worked out the pattern the long tail costs almost nothing to redirect.

Use the old thread ID as the join key

Titles get edited and slugs change, but almost every forum puts a stable numeric ID in the thread URL:

• Discourse: /t/topic-slug/12345, plus per-post URLs like /t/topic-slug/12345/7
• Higher Logic Vanilla: /discussion/4597/topic-slug
• Gainsight Customer Communities (formerly inSided): /category-8/topic-slug-31746

Ask your new vendor to store the old ID on every imported post. Then the redirect map is a simple join on that ID instead of a fuzzy match on titles, and per-post URLs can point at their thread with one rule.

Decide where each kind of page goes

Threads are only part of the list. Decide every page type up front so nothing defaults to the homepage.

Redirects that keep your rankings

This is the part that carries your rankings across, so it's worth getting boringly right.

Permanent, server-side, one hop

Use permanent server-side redirects, 301 or 308. Google recommends them wherever possible and says permanent redirects don't cost PageRank. JavaScript or meta refresh redirects are a last resort.

Go straight to the final URL. Google follows up to ten hops but advises keeping chains short, and every hop adds latency. Old forums often carry redirects from an earlier migration, so flatten those to the new destination instead of stacking a fresh hop on top.

Never send a pile of threads to the new homepage. Google's guide is blunt about it: many old URLs pointing at one irrelevant page, such as the home page, may be treated as a soft 404. You keep the redirect and lose the ranking.

Decide who serves the redirects

Settle this one first. The answer turns on a single decision: whether the hostname stays the same.

If the hostname changes (say forum.example.com becomes community.example.com), the old hostname has to stay alive just to answer redirects. Keep its DNS and SSL certificate, put the redirect rules on a CDN or a small server in front of it, and submit a Change of Address in Search Console. Google says that tool is for moves between domains or subdomains, not for path changes on the same host.

If you keep the hostname, you skip Change of Address, and every old path now lands on the new platform. Something has to answer /t/topic-slug/12345 with a 301: the new platform's redirect feature or a proxy in front of it. Ask your vendor exactly how that works before you sign, and test a list of old URLs on staging. On Bettermode a custom domain comes with every plan, so keeping the hostname is an option.

Keep them for at least a year

Google says to keep redirects as long as possible, generally at least a year, and its Change of Address help asks for at least 180 days and longer while they still get traffic. It also suggests paying for the old domain for at least a year so nobody else picks it up.

I'd keep them forever. A redirect rule costs nothing to keep, and the blog post that linked to your thread in 2019 will still be online in 2030.

Bring the answers across with the threads

A thread that arrives without its accepted answer, its original author or its original date has lost most of what made it worth ranking. Check these in the import, before cutover:

• Accepted answers: make sure the solved marker maps to the new platform's equivalent. Google's Q&A structured data has an acceptedAnswer property, and it points forum-style threads that aren't Q&A at discussion forum markup. Run ten migrated threads through Google's Rich Results Test and see what the new platform outputs.
• Authors and dates: keep the original author and post date on every thread and reply. An answer from 2021 that suddenly says "posted today" misleads readers.
• Attachments and images: re-host them on the new platform. Links to the old platform's file storage break the day that contract ends.
• Links inside posts: rewrite them to the new URLs using the map. Otherwise every internal link costs a redirect hop, forever.

Don't use the move as an excuse to prune hard. If a thread is dead, decide in the map whether it merges into a better answer (301 to that answer) or goes away (410). Google's guidance is to return a 404 or 410 for content you don't move.

Member accounts and single sign-on

Import members with their email addresses, so accounts match the first time someone logs in, and keep display names so attribution on old threads survives.

Passwords are the awkward part. Assume members who log in with a local password will need a reset unless both vendors confirm the hashes carry over, and write that email before cutover day, not after the support queue fills up.

If members log in through your product with single sign-on, keep the same identity provider and match on email. A Discourse community using DiscourseConnect needs its replacement configured and tested with staff accounts before launch. On Bettermode, OAuth2 and JWT come on Growth and Premium, and SAML on Premium.

Cutover day: canonicals, sitemaps and Search Console

Cutover day is mostly checks. The ones that catch real problems:

• Every new URL carries a self-referencing canonical tag, which Google's guide asks for.
• Any noindex tags or robots.txt blocks from staging are gone. A leftover staging noindex is the classic cutover bug.
• The new sitemap is generated and submitted in Search Console. If the hostname changed, both the old and new properties are verified.
• Every row of the URL map has been crawled: one 301, a final 200, and the destination the map says. A crawler in list mode or a short script does this in minutes. Spot-check a few rows with URL Inspection.
• Links you control point at new URLs: help center, docs, product UI, site navigation, email templates, chatbot sources.

Hand off through a read-only period

Don't flip everything at once. Announce the move, set the old community to read-only, migrate, then redirect. A read-only window freezes the content so the export matches what's live, stops members from posting into a forum that's about to disappear, and gives people a few weeks to find the new place.

Webflow did it in that order when it moved its forum to Bettermode. On February 2, 2026 a notice on the old Discourse forum said it would go read-only on February 17 and be deprecated in April as content and members moved to the new platform. Today discourse.webflow.com answers with a 301 to community.webflow.com (I checked on October 13, 2026).

What you don't want is both versions live and indexable for months. Two copies of every thread split your signals and confuse members about where to post.

The first weeks after cutover

Expect a dip and plan for it. For the first two weeks I'd recrawl the old URL list every day, then weekly through day 90. In Search Console, watch the Pages report for new "Not found (404)" rows and the Performance report by page. Fix stragglers as they show up. They're almost always a URL pattern the map missed.

Search Console will also mislead you here. We consolidated a batch of older blog posts on bettermode.com this year, first in the January relaunch and again in a smaller cleanup over the summer. Weeks after the 301s went live, Search Console was still crediting impressions to the old URLs as if they were live pages, and I nearly recommended redirecting two pages that had already been redirected. Check the live status code before you act on any row in that report.

The other lesson was harder. Where a merged page didn't answer the question the old post had answered, the clicks never came back, even with a clean redirect. A redirect can only send people to a page. If the page doesn't answer them, they leave.

What to measure

Compare everything against the same number of weeks before cutover:

• How many mapped URLs return a single 301 to a live page. Every row on your top-traffic list should.
• New URLs indexed against new URLs submitted, from the Sitemaps and Pages reports.
• Weekly organic clicks and impressions to the community.
• Positions for your 50 most valuable threads. Put those rows from the map into a rank tracker.
• The URL that ChatGPT, Perplexity and Google's AI Mode cite when you ask them the questions your community answers. You want to see the new ones.
• Weekly active members and new posts, so you catch the people who never found the new address.

For the community side of the numbers, our guide to community manager metrics goes further, and forum SEO and AEO covers getting the new community ranking once the move is done.

Getting help with the move

Before you sign with any platform, ours included, get straight answers to four questions:

• Will the old thread IDs be stored on imported posts?
• Who serves the redirects on cutover day, and can we test a list of old URLs on staging first?
• Do accepted answers, authors and original dates come across?
• How do members log in on day one, and what happens to local passwords?

If you're moving to Bettermode, migration support is an add-on on the Growth and Premium plans (see pricing). Our team moves your users, content and space structure, and plans the cutover so the community stays up while it happens. Talk to us about your migration.

Still choosing where to go? Start with our roundups of Discourse alternatives, inSided alternatives, Vanilla Forums alternatives and Circle alternatives.

Toggy runs on Bettermode. If your community lives on Discourse, Circle or inSided today, the Toggy demo starts with Build. Book a Toggy demo →

FAQ

How do I migrate an online community to a new platform without losing SEO?

Build a URL map before anything moves, with one row per old URL and its new destination. Redirect every thread to its matching new thread with a single permanent 301, keep accepted answers, authors and dates, give new pages self-referencing canonicals, submit the new sitemap, and keep the redirects live for at least a year. Then watch Search Console for several weeks and fix any URL the map missed.

Will moving my forum to a new platform hurt my Google rankings?

Expect a temporary dip even when everything is done right. Google says a medium-sized site can take a few weeks or more for the new URLs to replace the old ones, and larger sites take longer. Lasting losses come from missing or irrelevant redirects, threads that lose their accepted answers, and pages that no longer answer the question the old URL ranked for.

How long should I keep 301 redirects after a community migration?

Google recommends keeping redirects as long as possible, generally at least a year, and its Change of Address help asks for at least 180 days and longer while the old URLs still get traffic. In practice, keep them indefinitely. Old backlinks to your threads stay on other sites for years, and a redirect rule costs nothing to keep.

Can I redirect all my old forum threads to the new community homepage?

No. Google says sending many old URLs to one irrelevant page, such as the home page, may be treated as a soft 404, so the old rankings don't carry over. Redirect each thread to the same thread on the new platform. For content you deliberately don't move, Google's guidance is to return a 404 or 410 instead.

Should the new community keep the same domain?

Keeping the same hostname is simpler for search, because you skip a domain move and only the paths change. The catch is that the new platform, or a proxy in front of it, has to answer the old paths with 301s. If the hostname changes, keep the old one alive to serve redirects and submit a Change of Address in Search Console.

How do I keep member accounts and logins when switching community platforms?

Import members by email so accounts match on first login, and keep display names so authorship on old threads survives. Assume members with local passwords will need a reset unless both vendors confirm otherwise, and send that email at cutover. If members sign in through your product with single sign-on, keep the same identity provider and test it with staff accounts first.

How long does it take Google to pick up a migrated community?

Google says a small to medium site can take a few weeks for most pages to move in its index, and larger sites take longer. Submitting the new sitemap helps discovery. Track indexed against submitted URLs in Search Console, and don't read too much into old URLs that still show impressions for a few weeks after their redirects go live.

Does Bettermode help with community migrations?

Yes. Migration support is an add-on on Bettermode's Growth and Premium plans. The team moves your users, content and space structure from your current platform and plans the cutover so the community stays up during the switch. Whichever vendor you pick, ask who serves the old-URL redirects on cutover day and test a list of old URLs on staging before launch.

TL;DR

• Build the URL map first: every old URL that earned clicks or links, joined on the old thread ID.
• One permanent 301 per thread to its matching new thread. No chains, no homepage dumps.
• Keep redirects at least a year (Google's number). Forever is better.
• Carry over accepted answers, authors, dates, attachments and in-post links.
• Import members by email, plan the password reset, and keep the same SSO identity provider.
• On cutover: self-referencing canonicals, no leftover noindex, new sitemap submitted, Change of Address if the hostname changes.
• Go read-only before you redirect, then watch Search Console for weeks and check live status codes before acting.