Wix Studio

How we built charusolutions.com on Wix Headless and Astro

ANKIIT 21 October 2026 · 4 min read

Most agency sites describe what they can build. Ours is the build: charusolutions.com runs on Wix Managed Headless with an Astro frontend, and every claim on our Wix Headless page can be checked against the page you're reading it on. This is how it's put together, what it made possible, and what we'd still improve.

The stack

Frontend: Astro 5 with server output; React islands only where a page needs interaction
Hosting: Wix Managed Headless — Wix builds, deploys, hosts and secures it
Content: Wix Data collections for services, case studies and cities; Wix Blog
Business: Wix Bookings with Wix checkout, Wix Forms, Wix Members
SEO: @wix/seo for dashboard-controlled tags, plus our own per-route metadata, schema and sitemap

The team edits everything in the normal Wix dashboard. A new case study, blog post or booking slot appears on the site with no deploy. Only design and page structure live in code.

Decision 1: render on the server

Every page arrives as complete HTML. That matters more than it used to: most AI crawlers don't execute JavaScript, so a client-rendered site shows them an empty shell. With Astro's server output, the text is in the markup — view source on any page and it's there.

Interactive pieces (the booking widget, the contact form, our free SEO tools) are React islands that hydrate on their own. Everything else ships as plain HTML.

Decision 2: own the SEO layer

Wix handles SEO tags for its own item pages — blog posts and booking services pick up their titles and descriptions from the dashboard through @wix/seo. But pages built from our own CMS collections (services, case studies, city pages) would otherwise inherit their parent section's tags. Early on that meant dozens of URLs sharing two titles and no descriptions.

So one component, PageSeo, renders the title, description, canonical, Open Graph tags, breadcrumbs and JSON-LD for every custom route, generated from the CMS record. Two details worth copying:

Titles never get a chopped brand name. If "… | Charu Solutions" won't fit, the whole suffix is dropped rather than cut mid-word.
Canonicals ignore query strings. Our filter links (/projects?industry=…, /blog?category=…) were each being treated as a separate page. Stripping the query from the canonical consolidated them into the unfiltered page — one change that cleared 30 duplicate titles and 30 duplicate descriptions in our site audit.

const pageUrl = new URL(forwardedUrl ?? Astro.url.href);
pageUrl.search = '';
pageUrl.hash = '';
const canonical = pageUrl.href;

FAQ structured data is generated from the same array that renders the visible questions, so the schema can never describe something that isn't on the page.

Decision 3: our own sitemap

Wix's sitemap knows about Wix's own pages. It doesn't know about a project page built from a custom collection. Our sitemap is an Astro endpoint that reads the same CMS queries the pages use — services, every case study, every published city, blog posts, bookable services — so a new record is listed the moment it's published. City × service pages are only listed for cities explicitly opted in, which keeps near-duplicate pages out of Google's crawl queue.

Decision 4: keep the search history from the old site

Before this build, the domain ran a classic Wix site. Search Console showed 91% of its impressions going to URLs that no longer existed — one old blog post alone carried most of them — plus a tree of two-letter language prefixes from Wix Multilingual that Google still requested.

Astro middleware now 301-redirects every one of those addresses to its nearest live equivalent in a single hop, including the language-prefixed versions. Pages with no honest equivalent (old policy pages) are deliberately left to 404, because redirecting them somewhere unrelated is a soft 404.

Decision 5: backend endpoints Wix Studio couldn't give us

Because the frontend is ours, it can have API routes running on Wix's infrastructure. Our free tools — the Wix SEO checker, AI crawler checker, AI readability checker, llms.txt generator and MCP endpoint checker — are all server-side endpoints that fetch and parse other sites. That's not something a site builder can do.

Decision 6: retire things in code, not in the dashboard

Some content shouldn't be on the site but shouldn't be deleted either — template booking services that came with Wix Bookings, a case study whose client site isn't finished. We filter them in the data layer, so the listing, the detail page, the counts and the sitemap all agree, and the old URL 301s away. The decision is in version control, where anyone can see why.

The results

Site audit (Ubersuggest): 72 → 96 after the title, canonical and thin-content fixes, across 169 crawled pages with zero broken links.
Desktop: largest contentful paint around 1.1 s, layout shift effectively zero.
Content team: unchanged workflow — everything is still edited in the Wix dashboard.

What we'd still improve

Honesty helps here. Mobile first load is slower than we'd like — about 4 s in lab tests. Two causes: the bare charusolutions.com address redirects to www (about 1.1 s on a throttled mobile connection), and the first request to a cold serverless instance takes 1.4–1.9 s before the server responds. Neither is something page code can fix, so we keep JavaScript light and images on Wix's media CDN in AVIF to win back what we can elsewhere.

Should you build this way?

Usually not — and we say so on our own Wix Headless page. If your team needs to change layouts themselves, Wix Studio is the better tool. Headless is worth it when you need server-rendered output for search and AI crawlers, your own endpoints, or a frontend shared with another product. If that's you, talk to us — or start with what Wix Headless actually is.

All insights