Migrating your knowledge base without losing SEO traffic

For many products, the help center is the highest-traffic property they own after the homepage. Years of "how do I connect X" and "why is Y not working" articles quietly rank for thousands of long-tail queries, deflect tickets around the clock, and bring in buyers who started with a problem search. A knowledge base migration that ignores this burns compounding value that took years to build — and the loss shows up weeks later, when it's hardest to reverse.

The good news: search engines handle site moves well when you follow a short list of non-negotiables. Here's the list.

First, measure what you're about to move

You can't protect traffic you haven't measured. Before a single article moves:

• Pull the last 12 months from Google Search Console: pages, queries, clicks and impressions. Export it — this is your baseline and your insurance policy.
• Crawl the old help center to get the complete URL list, including category pages, redirects that already exist, and articles nobody remembers publishing.
• Mark the money pages: the top 20 articles by clicks typically carry the large majority of organic traffic. These get hand-checked at every later step.
• Note which URLs already redirect — chained redirects are one of the classic ways link equity leaks during a move.

Decide the URL story before anything moves

Every article needs a deliberate answer to "what is your new address?" — recorded in a mapping table with old URL, new URL, and status.

• Keep slugs identical wherever possible. If the old article lived at /hc/articles/12345-connect-your-inbox, and the new system supports /help/connect-your-inbox, carry the human-readable part over unchanged.
• If the help center moves between domains or subdomains (support.example.com to example.com/help, say), treat it as a site move: the redirect map matters even more, and you should verify both properties in Search Console.
• One-to-one mapping is the rule. Every old URL points to its direct equivalent. Redirecting everything to the new help center homepage is the single most common way teams destroy their rankings — search engines treat mass homepage redirects as soft 404s.
• Articles you're deliberately retiring get a redirect to the closest surviving article, or an honest 410 if nothing covers the topic. Decide per article, not per policy.

Redirects: the non-negotiables

• 301, permanent. Not 302, not JavaScript redirects, not meta refresh. A 301 tells search engines to transfer the ranking signals.
• Maximum one hop. Old URL to final URL directly. If the old center already had redirects, flatten the chains in your map.
• Keep the old domain or path serving redirects for at least a year. Search engines revisit slowly; link equity transfers over months, not days. Cancelling the old subdomain the week after cutover cuts the transfer mid-flight.
• Test the map programmatically. A script that requests every old URL and asserts a 301 to the expected target takes an hour to write and catches the typos that would otherwise cost rankings silently.

Slugs, titles and canonicals

• Every migrated article carries a self-referencing canonical tag on its new URL.
• During any parallel period where both help centers are live, the old articles must not compete: either serve the redirects immediately at cutover, or set canonicals from old to new. Two live copies of the same article split ranking signals between them.
• Keep titles and H1s stable through the move. A migration is the wrong moment for a rewrite — change one variable at a time, and let the URL move settle before editing content.
• Regenerate and submit the XML sitemap of new URLs on day one, and keep the old sitemap available briefly so crawlers discover the redirects faster.

Sanitize the HTML on the way in

Legacy help centers accumulate markup debt, and imports faithfully copy it:

• Strip inline styles and vendor-specific classes — they fight the new theme and occasionally break mobile rendering, which is itself a ranking factor.
• Rewrite image references to files you re-hosted; hotlinks to the old vendor's CDN die when the account closes. Add alt text while you're there — most legacy KB images have none.
• Fix heading hierarchies: old editors loved skipping from H1 to H4. Clean structure helps both readers and the featured-snippet eligibility your best articles enjoy.
• Remove dead embedded widgets — old chat launchers, feedback forms and scripts that point at the system you're leaving.

Internal links are part of the migration

Article-to-article links inside the KB should be rewritten to the new URLs at import time — leaning on redirects for internal navigation works, but it wastes crawl budget and slows everything down. The links outside the KB matter just as much: in-app help links, onboarding emails, macros and saved replies all point somewhere. Grep every surface you control for the old help center domain and update at the source.

Rehearse the move on a staging copy

Everything above can be tested before a single visitor is affected. Import the articles into the new help center unpublished (or behind a staging domain), run your crawler against it, and compare: article count matches the source, headings survived, images resolve from the new host, and internal links point at new URLs rather than old ones. Then dry-run the redirect map against the staging host with the same test script you'll use on launch day. Teams that rehearse find their mapping-table typos on a Tuesday afternoon; teams that don't find them in the 404 log with search traffic attached. The rehearsal usually takes half a day and converts launch day from an event into a checklist.

After launch: watch the right dashboards

• 404 log, daily, for the first two weeks. Every 404 from a search referral is a mapping-table bug you can fix the same day.
• Search Console coverage: watch new URLs get indexed and old ones drop to "redirected". Slow is normal; errors are not.
• Rankings on the money pages from your baseline export. A modest wobble for two to six weeks is standard for a well-executed move; a cliff on a specific page means its redirect or canonical is wrong — check it first.
• Expect full stabilisation in one to three months. Judge the migration then, against the baseline you saved, not in the first noisy week.

Where MoveDesk fits

MoveDesk's knowledge base import was built with this list in mind: articles arrive with structure and visibility flags preserved, images re-hosted, and clean HTML that fits the new theme. And because your KB doubles as the grounding source for MoveDesk's AI agent, the same cleanup pays twice — tidy articles rank better and answer customers more accurately. The white-glove migration handles the import; the redirect map stays in your hands, because it lives on your domain.

Before you migrate a single article, export your Search Console baseline. Everything else on this list can be fixed after cutover — a missing baseline cannot.