You can move the site customers read without moving the inbox your team works in. Keep Zendesk ticketing, agent workflows, and support addresses in place. Move the help center only after you have verified that customers can still find articles and reach support.
1. Inventory what is live
Start with the canonical URL, article ID, locale, category, section, publication state, and audience for each article. Include attachments, inline images, and links to pages behind sign-in. Use Zendesk's export options and Help Center Articles API as starting points. An API export is an inventory input, not proof that every localized or restricted page migrated correctly.
Use Search Console and your support macros to identify pages people actually depend on. Add columns for the target URL, redirect owner, and reviewer. Keep drafts and restricted content separate from the public import.
2. Review a private draft before moving everything
Pick a top search landing page, an image-heavy troubleshooting article, a localized article, and a restricted page if your site has one. Import or recreate the samples in a private preview. Check navigation, mobile layout, code blocks, screenshots, search, and links to attachments. Verify access as both an authorized and an anonymous visitor.
If you only want to test DocsAlot, start with the Zendesk comparison and migration preview. Review what renders and what needs manual handling before planning a full move.
3. Decide which URLs you can preserve
If you control the public help-center hostname, aim to keep the domain and important paths unchanged. Map each changed path to its closest replacement and configure a permanent redirect where you control the old URL. A hostname under zendesk.com is not yours to redirect at the DNS layer. Confirm what Zendesk can serve at those old addresses before taking anything down.
Run the URL map against the preview and check status codes, canonicals, internal links, and sitemap entries. Do not send unrelated old articles to the homepage. Follow Google's site-move guidance for changed URLs. A careful migration reduces risk, but does not guarantee rankings stay flat.
4. Test what happens when a customer still needs help
Open the new help center as a signed-out customer. Submit a test request and verify it arrives in the intended Zendesk queue with the right form fields. Test contact links, widget or sign-in behavior if you use it, and links in macros and automated replies. If your form lives on the old help center, keep a working Zendesk destination or verify an alternative before switching the hostname.
5. Switch only when you can roll back
Freeze article edits briefly or re-export the changes since your first copy. Keep the old site and routing configuration available during the transition. After cutover, test the top old URLs, watch for new 404s and broken images, and monitor Search Console and ticket volume. A broken contact path or exposed restricted content is a reason to roll back immediately.
Use the customer support automation guide to decide which recurring issues to fix before the move. If you are comparing the result with your current site, see the Zendesk alternative page and the branded help center hub.