appfarms.com — from WordPress to Astro

About this project

This reference is an in-house project: the migration of our own website appfarms.com from a long-grown WordPress installation to a statically delivered Astro stack. We document the project openly — including the rough edges — for two reasons.

First, because we want to be measured by what we recommend to clients: a modern web that is fast, secure, maintainable and durable. Second, because the pain points that triggered our migration are the same in many companies — and an honest experience report is worth more than any glossy bullet list.

Starting point: what no longer fit on WordPress

The old site ran reliably — but it kept demanding attention without delivering editorial benefit in return:

• Plugin and core updates as a recurring maintenance task, with the risk of incompatibilities and breaking changes.
• Security surface: PHP runtime, database, third-party plugin code and a public login — every element is a potential attack vector and requires patch discipline.
• Performance despite caching: good scores required additional plugins whose configuration had to be re-tuned regularly.
• Editor and page-builder fragmentation: content was partly in the block editor, partly in the page builder, partly in plugin custom fields. Structured content (case studies, FAQs) was hard to keep consistent.
• Reproducibility: staging and local environments were laborious; database and media sync was a recurring source of friction.

None of this is an argument against WordPress in general. For our profile — a primarily editorial marketing and references site with a moderate change cadence — the ratio of complexity to benefit had simply become unfavourable.

What an external audit of the old site revealed

Before the migration we ran a passive external review of the live WordPress installation — no login, no active exploits, only publicly reachable endpoints. The findings were typical for a long-grown WP site, by no means unusual, but unambiguous:

• User enumeration via /wp-json/wp/v2/users exposed the admin login slug without authentication — a perfect template for targeted brute force.
• Author-slug leak via ?author=1, which redirected to the same login name.
• Missing security headers on public pages: no HSTS, no CSP, no X-Content-Type-Options, no X-Frame-Options, no Referrer-Policy, no Permissions-Policy.
• Version fingerprinting through x-powered-by: PHP/8.2.28, publicly accessible readme.html/license.txt, and plugin versions exposed in markup.
• Application Passwords enabled without enforced 2FA — long-lived API tokens as a realistic follow-up vector.
• wp-cron.php publicly triggerable, a classic DoS amplifier.

None of these are scandals — each can be closed with WP built-ins, plugins or webserver rules. But each is also recurring maintenance work that comes back the moment plugins update, a new theme is added, or hosting changes. Exactly that ongoing duty was what we wanted to retire — not WordPress as such.

Decision: why Astro

We seriously evaluated three options: modernising WordPress (clean-up, plugin reduction, headless frontend), a Hugo/Eleventy solution, and Astro. We chose Astro because, for our profile, it offers the best combination:

• Static delivery by default — no PHP, no DB, no login. The attack surface shrinks to the files we ship.
• Component model with TypeScript, without forced SSR and without framework lock-in. We can drop in React/Svelte islands when needed — but don’t have to.
• Content collections with a Zod schema: content is validated at build time. A missing required field breaks the build instead of going live unnoticed.
• Multilingual setup cleanly as a directory structure (de/, en/), not as a plugin.
• SEO essentials (sitemap, JSON-LD, hreflang, canonical) live in code — versioned and reviewable, not in a plugin backend.

Migration path

1. Content audit: every WordPress page evaluated (keep, rewrite, drop, merge). Result: significantly fewer but stronger pages.
2. Content model before content: schema for pages, case studies and FAQs defined in content.config.ts before migrating content. That surfaced several inconsistencies from the old site.
3. Markdown migration: content carried over as Markdown, images optimised, alt texts added.
4. Redirect map: 1:1 mapping of old URLs to new slugs to preserve rankings and backlinks.
5. SEO building blocks: JSON-LD for organisation, breadcrumbs, FAQs and case studies; clean <title> and meta descriptions per page.
6. CI/CD: build and deploy run automatically; every push to main is a deploy, every PR gets a preview.

Results

What changed noticeably in practice:

• Maintenance: no plugin updates, no PHP patches, no login hardening. Updates are limited to dependencies that are visible in PR review.
• Performance: static HTML with minimal JS. Core Web Vitals are in the green without a caching plugin. (Concrete before/after metrics — Lighthouse, TTFB, LCP — to be added after final launch.)
• Editorial workflow: a new reference or service equals a new Markdown file with a schema. Consistency is enforced by the system, not by discipline.
• Security: no public database, no login endpoint, no third-party plugins in the delivery path. The vectors found in the audit (user enumeration, author-slug leak, missing headers, application-password endpoint, public wp-cron) simply don’t exist on a statically delivered site; security headers are set centrally at the edge and versioned in the repository.
• Cost: simpler hosting, fewer maintenance hours. (Exact numbers will be measured during operation.)

Lessons learned — honestly

• The content schema is the most important decision, not the framework. Whoever defines the data structure cleanly wins regardless of stack.
• Migration is 70 % content work, 20 % SEO/redirects, 10 % technology. Reversing that ratio underestimates the effort.
• Astro is not the right choice for every site. For highly dynamic, logged-in or heavily editorial scenarios, other stacks may fit better.
• “No CMS” doesn’t mean “no editorial process”. With a non-technical team, plan in a lightweight editor frontend — Astro keeps that option open.

What does this mean for your project?

If you run a website that primarily serves marketing, reference or product content, where security and performance are high priorities and maintenance effort has become noticeable, an Astro-based stack deserves an honest look. We accompany migrations like this — from content audit through schema design to an SEO-preserving go-live. Feel free to get in touch.