Migrating a WordPress Site to a Custom Astro + Supabase CMS

Why Migrate Off WordPress at All

WordPress gets a business to launch fast, but for a content-heavy site with real operational needs — multiple content types, an admin team that isn't technical, and a business that depends on search rankings it's already earned — it starts working against you: plugin conflicts, slow page loads from accumulated bloat, and a content model that doesn't match how the business actually operates. That was the situation with Khales Advisory, a Moroccan food-safety consultancy specializing in ONSSA agrément and HACCP/ISO 22000 compliance — the WordPress site had become fragile, and every content update risked breaking something.

The Real Risk: Losing Search Rankings

The single biggest risk in any URL-changing migration isn't the rebuild itself — it's losing the search visibility the old site already earned. Before writing a line of the new site, I mapped every existing WordPress URL to its new Astro equivalent and built the migration around three non-negotiables:

• 301 redirects for every old URL, not a blanket redirect-to-homepage fallback, which is the single most common way sites lose rankings during a migration.
• A fresh, accurate sitemap submitted to Search Console immediately at launch, so Google can re-crawl the new URL structure quickly rather than discovering it gradually.
• Search Console monitoring in the weeks after launch specifically watching for crawl errors and indexation drops, so any redirect gap gets caught and fixed within days, not months.

Replacing WordPress With a Custom Headless CMS

Rather than a generic headless CMS product, I built a purpose-fit admin dashboard on top of a Supabase (Postgres) content model — services, blog posts, testimonials, team members, and media, each with their own schema matching exactly what the business needs, not a generic "post" and "page" model stretched to fit. The admin panel itself is a separate React SPA (React Router, TanStack Query, Tiptap for rich text) talking to the same Supabase backend as the public site through Astro Actions for CRUD — so content changes are immediate, with no caching layer to invalidate or plugin to misconfigure.

Why Astro Specifically

The public-facing site runs server-rendered Astro with the Node standalone adapter, with React islands only where actual interactivity is needed (forms, animated marquees) rather than shipping a full framework bundle for a mostly-static content site. This is close to the opposite of WordPress's model, where every request runs through PHP and a stack of plugins regardless of how simple the page actually is — the result is a genuinely fast site without needing a caching plugin to compensate for the underlying architecture.

What Made This Migration Low-Risk

• Content model designed around the actual business (services, compliance case studies, team, testimonials) rather than force-fit into generic WordPress post types
• Role-gated authentication on the admin panel so different staff can manage their own content areas without full-site access
• A transactional email pipeline (Resend) for contact form auto-replies and internal notifications, replacing a WordPress plugin dependency with code the client fully owns
• JSON-LD structured data built in from the start rather than retrofitted via an SEO plugin

Conclusion

A WordPress-to-custom migration is only worth the effort if you treat URL preservation as seriously as the rebuild itself — the technology upgrade is worthless if it costs the client their existing search rankings. Done carefully, the result is a site that's faster, easier for non-technical staff to manage day to day, and built around the business's actual content model instead of a generic one. See the full Khales Advisory case study for the complete tech stack and feature breakdown.