To migrate a help centre without breaking links, keep the same article addresses on the same domain wherever the new platform allows it. Where an address has to change, add a permanent (301 or 308) redirect from the old URL straight to the new one. Then move images you control, update internal links, submit the new sitemap and check every old URL still lands on the right article.
Why links break in a migration
Every help centre platform has its own address format. Zendesk’s look like /hc/en-us/articles/123456-Installation-and-setup, Help Scout Docs’ like /article/100-my-article, Intercom’s include an ID and a slug under /articles/, and Document360 uses a fixed /docs/ path. Move platforms and every address changes unless you do something about it.
Links point at those addresses from more places than you’d expect:
- Search results. Each article’s ranking belongs to its URL.
- Your own product: help links in settings screens, error messages and onboarding.
- Your website, emails, saved replies, chat widget and old support conversations.
- Other sites: forums, partner docs, blog posts and AI assistants that cite your articles.
- Customers’ bookmarks.
Only the first is easy to see. That’s why the safest migration is the one where the addresses don’t change.
Before you move: list everything
Build a spreadsheet of every URL the old help centre serves before you touch anything.
- The sitemap. If the help centre publishes one, usually at
/sitemap.xml, it’s the quickest complete list of articles. - Search Console and analytics. Export the pages that get search traffic and visits. These are the ones you can’t afford to break.
- Links from your product. Search your codebase for the help centre’s domain. Product links are often hard-coded and forgotten.
- Images and attachments, and where they’re hosted.
- Existing redirects on the old platform. Old URLs that already redirect still need to land somewhere after the move.
- Categories, languages and versions, each of which may have its own pages and addresses.
Keep the same URLs if you can
A URL has two parts that matter here: the domain (help.example.com) and the path (/article/100-my-article).
The domain
If your help centre is on your own domain, such as help.example.com, you control where that name points, so you can move it to a new platform with a DNS change. If it’s on the vendor’s address, such as a subdomain of their domain, you don’t control it, and the old URLs will only redirect if the old vendor lets you set that up. If you’re on a vendor address today, moving to your own domain as part of the migration means you won’t face this problem again.
The path
Some platforms generate paths in their own format and won’t let you change them. Others let you set any path per article. If the new platform can serve each article at its old path, the migration needs no redirects at all for articles, which is the best outcome: nothing for search engines to re-learn and nothing that can be forgotten.
Redirect everything that changes
Where an address has to change, a redirect tells browsers and search engines where it went. The rules:
- Permanent, not temporary. Google treats a 301 or 308 redirect as a signal that the new URL should replace the old one in search. A 302 or 307 isn’t treated that way.
- Straight to the final address. Avoid chains (old → older → new). Each hop is a chance for something to break.
- To the closest equivalent. Send each article to its own replacement. Redirecting everything to the home page loses the reader and the ranking.
- For at least a year. Google recommends keeping redirects as long as possible, generally at least a year. For a help centre, keep them for good: links in old emails and product versions live for years.
- Server-side. A redirect done with JavaScript or a meta refresh is weaker and slower.
Redirects have to be served by whatever answers on the old address. If the domain moves to the new platform, the new platform must serve them. If the old address stays with the old vendor, the old vendor must.
Images and attachments
This is the step people miss. Screenshots in a hosted help centre usually live on the vendor’s servers. An import that copies the article text keeps pointing at those images, and they may stop loading when you close the old account.
- Find out from the old vendor whether images stay available after you cancel. Assume they don’t unless they say so.
- Re-upload images to the new platform, or to storage you control, before you cancel.
- Do the same for PDFs and other attachments.
- Keep each image’s alt text. It’s what search engines and AI assistants read.
Categories and internal links
Categories
Category and collection pages have addresses too, and they get linked and indexed. Rebuild the same groups on the new platform where it makes sense, and redirect old category pages to the closest new one, or to the help centre’s home page if there’s no equivalent. A migration is also a good moment to fix a structure that no longer fits, as long as the article addresses stay put.
Links between articles
Articles link to each other using the old addresses. Redirects will catch them, but update the links themselves so readers don’t go through a redirect on every click. A search for the old domain or the old path prefix across all articles finds them.
Links from everywhere else
Update links in your product, website, email templates, saved replies and chat widget. If the URLs didn’t change, there’s nothing to do here, which is another reason to keep them.
Search engines
- Submit the new help centre’s sitemap in Google Search Console and Bing Webmaster Tools.
- Use Search Console’s Change of Address tool only if you moved from one domain or subdomain to another. It isn’t needed when only paths change.
- Inspect a handful of the most important old URLs to confirm Google sees the redirect or the same page.
- Watch the Page indexing report for new “Not found (404)” URLs for a few weeks, and redirect any you missed.
- Expect some movement in rankings while search engines recrawl, less if the URLs didn’t change.
Notes by platform
Zendesk
Zendesk’s help centre (managed in what Zendesk now calls Knowledge admin, formerly Guide) has no built-in export: articles come out through the Help Center API. Article addresses look like /hc/en-us/articles/123456-Installation-and-setup, with a locale and a numeric ID, so few other platforms can reproduce them. Zendesk’s redirect rules, set up through its API, only apply to URLs that return a 404 in Zendesk, so an article has to be archived or deleted first. They’re useful if you keep a Zendesk help centre running on its old address while moving some content elsewhere.
Help Scout Docs
Docs articles live at /article/100-my-article: a number and a slug. There’s a Docs API for getting articles, categories and collections out. Docs supports a custom subdomain (not a root domain or a path on your main site), and has its own redirects under the Docs site settings. If your Docs site is on your own subdomain, you can point it at a new platform that keeps the /article/ paths, and links carry on working.
Intercom Articles
Intercom says it isn’t possible to export articles from inside the workspace; use its REST API to list them. Article addresses contain a numeric ID and a slug (Intercom’s own help centre uses /help/en/articles/56644-customize-your-help-center), and the help centre can sit on a subdomain or a path on your site.
Document360
Document360 exports a project as a ZIP on its Business and Enterprise plans, and exports to PDF. Its system-defined path, /docs/, and the version and language parts of the URL can’t be changed. Moving to Document360 from elsewhere, you’ll want its article redirect rules, which can be imported from a CSV.
Notion and Google Docs
If your help content lives in Notion, export it as Markdown and CSV (or HTML). Google Docs can download a document as Markdown from File, then Download. Markdown keeps headings, lists and links, which most help centre tools can import or paste. Published Notion pages have their own addresses, so treat them like any other old URL: list them and redirect them if they were public and linked.
Migration checklist
- 1
List every URL
From the old help centre’s sitemap, your analytics and Search Console. Include category pages, attachments and images, not only articles.
- 2
Decide each article’s new address
Keep the same path on the same domain where you can. Otherwise map every old URL to its new one in a spreadsheet.
- 3
Move the content
Import or copy the articles, re-host images and attachments you control, and rebuild the categories.
- 4
Fix internal links
Between articles, and to the help centre from your product, website, emails, saved replies and chat widget.
- 5
Set up permanent redirects
A 301 or 308 from every old URL that changes, straight to its final address.
- 6
Switch the domain
Point the domain at the new platform, then test old URLs from your list: each should load the right article.
- 7
Tell search engines
Submit the new sitemap. Use Change of Address only if the domain or subdomain changed.
- 8
Watch for a month
Check for 404s weekly. Keep the old account until you’re sure nothing still depends on it.