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.
Four things carry your search value, and a careless move can break any of them:
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.
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.
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.
Titles get edited and slugs change, but almost every forum puts a stable numeric ID in the thread URL:
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.
Threads are only part of the list. Decide every page type up front so nothing defaults to the homepage.
| Old page | Send it to | Notes |
|---|---|---|
| Thread or topic, including per-post URLs | The same thread on the new platform | One 301 per thread. This is where the search value lives. |
| Category or board | The matching space or category | Keep the structure close to the old one so the mapping stays obvious. |
| Tag page | The matching tag, or the parent space | Worth a row only if it earned clicks or links. |
| Member profile | The member's new profile, or the member directory | Little search value, but people do link to them. |
| Search results, sorted or filtered lists, pagination | The parent list, or let them 404 | Rarely worth carrying over. |
| Deleted, spam or empty threads | 410 | Google's guidance for content you don't move is a 404 or 410. |
| Attachments and images | Re-hosted copies on the new platform | Redirect the old file URLs only if they earned traffic or links. |
This is the part that carries your rankings across, so it's worth getting boringly right.
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.
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.
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.
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:
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.
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 is mostly checks. The ones that catch real problems:
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.
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.
Compare everything against the same number of weeks before cutover:
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.
Before you sign with any platform, ours included, get straight answers to four questions:
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 →
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.
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.
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.
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.
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.
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.
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.
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.