Zendesk with Astro
Zendesk can support the site, and the default install loads the widget everywhere while the help center quietly becomes a second property. Both are decisions worth making on purpose.
Zendesk at a glance
- What I do
- Add Zendesk chat, support routing or help-center content to an Astro site, with loading rules that protect the page and a deliberate plan for where the content lives.
- Typical setup
- Adds 2–4 days
- How it is bought
- Part of a migration scope, or a Continuous development request once the site is yours
- Category
- Support
Setup
How I set up Zendesk
The widget is the simple half. It should load only where support access helps the page, pass the context support needs, and stay out of the way where the page has a stronger call to action.
The help center is the bigger decision. If the content is purely support for existing customers, leaving it on Zendesk may be exactly right. If the docs, tutorials and knowledge-base articles are part of how people find you, then where they live, how they are linked and which URL is canonical all matter, and they are easier to settle before the content exists than after.
So I decide the content model first: keep it in Zendesk, surface selected articles on the site, serve it under the main site, or rebuild the important pieces as Astro pages. Then the widget and the routing rules support that decision rather than fighting it.
How the handoff works
- 01
Page
Where the widget loads, decided
Key handoff
- 02
Context
What it knows about the visitor
- 03
Ticket
Created with the page it came from
- 04
Help center
A second property, on purpose
- 05
Verify
Loading rules and routing checked
Why this is the key handoff
The widget and the help center are two decisions. One is what loads on the site and where. The other is a second property with its own domain, its own templates and its own search results, which is a thing to decide on purpose rather than to discover later.
Included
What gets connected
-
Zendesk Web Widget or messaging loaded where it belongs
-
Visitor and page context passed into support
-
Routing by page, product, plan or intent
-
Help-center content surfaced, linked or mirrored where appropriate
-
Loading rules that protect important landing pages
Before you add it
What to watch out for
- 01
Tickets need the right requester and routing context
Where a ticket arrives without the requester matched, or without the fields your triage rules read, your routing has nothing to act on and it waits wherever unrouted tickets wait. I pass the agreed context in at submission so the rules you already have can do their job.
- 02
Matching the site's design there is a second build
Guide themes are their own templating system with their own language, so nothing carries across from the site automatically. Matching the site there is a build of its own, and it is the difference between one brand and two.
- 03
Support code runs on pages that never need it
The default install puts a substantial script on every page, and it usually lands in the same corner as something else. I scope it to where support actually happens and check what it costs the pages that keep it.
More tools
Keep exploring
-
Intercom
Add Intercom to Astro with visitor context, secure identity for logged-in users and loading rules that protect page speed.
Adds 2–4 days
-
Google Analytics
GA4 and Tag Manager set up on an Astro site with clean events, consent behavior and performance-conscious loading.
Adds 2–4 days
-
Salesforce
Site forms that create the right Salesforce records, preserve attribution and fail visibly when Salesforce rejects a submission.
Adds 3–5 days
Let me plan your next step.
I can scope a migration. Send a brief and I will reply by email with next steps.