Static site with Astro: why migrate, without losing your SEO

What a static site means in 2026

A site running on WordPress, Drupal or Joomla builds every page at the moment a visitor asks for it: the server runs PHP, queries a database, assembles the template, then sends the result. That mechanism has a cost on every visit, a permanent attack surface, and an update debt someone has to pay every month.

A static site reverses the order: pages are built once, at publication time, and the result is a folder of HTML, CSS and image files. That folder is copied to a content delivery network (CDN) that serves it as is, from the point closest to the visitor. Nothing runs on the server side, because there is no application server any more.

The word is misleading: “static” does not mean frozen or without interactions. A form, an internal search, a calculator or a client area remain possible. They are wired to dedicated services, page by page, instead of forcing a full application onto the whole site.

What it changes, measured rather than promised

Speed. Google sets three thresholds for its Core Web Vitals: main content displayed in under 2.5 seconds, a response to interactions under 200 milliseconds, and visual stability under 0.1 (web.dev, official thresholds). A well-built static site reaches them without exotic effort, because it sends neither useless JavaScript nor pages assembled on the fly. On the home page of the site you are reading, built with Astro, the Lighthouse 12 measurement of 3 September 2026 in simulated mobile gives 0 milliseconds of main-thread blocking and 322 KB loaded in total. At the other end of our portfolio, our online store on Shopify, measured before its rebuild, showed a mobile score of 65, main content displayed at 8.4 seconds and a 4.2 MB page. The difference does not come from the teams’ talent: it comes from what the browser receives.

Security. Drupal 7 has been end of life since 5 January 2025 (drupal.org): no more security fixes, on a system nobody corrects any more. A static site has no database to protect, no exposed admin panel, no extension to patch. What remains to secure is the publishing chain, which lives in a Git repository with named access.

Cost of ownership. A static site costs its hosting, often a few euros a month, and zero licence. The monthly maintenance hours (core, extension and theme updates, database backups, restarts) disappear with the application server. What remains is the editorial work, the one you want to pay for.

Availability. A folder of files can be served from any host, including the one you already have, behind your current CDN. For a company that must stay readable from networks that block third-party scripts (mainland China is the common example), it is decisive: self-hosted fonts, no call to Google, no dependency that slows down or breaks the display.

Astro, in five technical points

Astro is a content-oriented site generator. Its current version is 7 (npm registry, 3 September 2026). This site runs on Astro 5 and our real-estate site on Astro 7. Five technical choices explain why we picked it.

1. HTML by default, JavaScript on demand. Astro renders components at build time and sends no JavaScript to the browser until a component asks for it. That is the islands architecture: a form or an interactive map carries its own code, loaded when it becomes visible. The rest of the page is inert and immediate.
2. Content validated by a schema. Pages and articles are declared in content collections with a schema: an article without a title, a description or a date does not build. What used to be checked by hand on a checklist becomes impossible to forget.
3. Any content source. Markdown files in the repository, a headless CMS like Sanity, a database or an API: Astro reads all of them at build time. The choice depends on who publishes and how often, not on the tool.
4. Static or server, page by page. A site can be fully static, or rendered on demand where content changes every minute. Our real-estate site uses server rendering because its listings change every day. This site is fully static. Same tool, same code.
5. The SEO foundation produced by code. Routes per language, reciprocal hreflang, a real sitemap, structured data per template, images converted and resized at build time: none of it depends on an extension to install or a setting not to forget.

The workflow: publishing is merging

The least visible part of a migration is the one that decides what comes next. With a static site in a Git repository, every change goes through an online preview and automatic checks before going live: dead links, pages without a title, sitemap, addresses. A publication is a merge. A rollback is one command. Nobody needs a tool installed on their computer, and an article published in six months follows exactly the same path as today.

It is also what makes a content engine possible: our SEO and GEO engine writes its drafts directly into the repository, and human review is the review of the change before merging.

The migration, step by step

The number one risk of a migration is not technical, it is in the addresses. Any URL lost without a redirect is destroyed traffic, and a ten-year-old site has hundreds that still receive visits or links. The method we apply has four steps.

1. The inventory. Crawl of the current site, the sitemap actually served, sixteen months of Search Console, and the list of pages not to break: those that receive traffic or inbound links, with their weight. The address contract is written before a single page is built.
2. The build. Content is extracted and reproduced as is, checked page by page. The design is kept or improved template by template. Redirects are set up on a pre-production you visit.
3. Acceptance. A crawl diff compares the old site and the new one, page by page: titles, descriptions, canonicals, internal links, HTTP statuses. The address matrix must be green before any switch.
4. The switch. Go-live, redirects active, fourteen days of monitoring of Search Console and errors, the old site ready to come back. The before and after measurement says what the migration changed.

We are running this method right now for a digital agency of about twenty people based in Shanghai: a 233-address site on Drupal 7, seventeen years of history, an accessibility constraint from China, a migration to Astro with unchanged addresses. The switch is planned for autumn 2026. The measurements will be published here, before and after, once they exist.

When not to migrate

A static site is not the answer to everything, and we would rather say so before the quote.

• A transactional online store (cart, stock, payment, customer accounts) belongs on an e-commerce platform, not a page generator. The catalogue can be static, the transaction cannot.
• An application with logged-in users who read and write data every minute needs server rendering or an application. Astro can do it, but it is no longer a static migration.
• A team of ten writers publishing every day needs an editing tool: that is the case of the headless site with Astro and Sanity, which keeps the visitor side static and adds a CMS on the team side.

In all three cases, the audit says so before you commit to anything.

What it costs

The migration to a static site with Astro is a closed-scope offer: from €5,900 excluding VAT for a site up to one hundred pages, four weeks, addresses kept, acceptance by crawl diff and monitored switch. A new site, with nothing to carry over, falls under the business website, from €3,900. In both cases, what remains afterwards is hosting and content.

Frequently asked questions

Will I lose my rankings by migrating? Not if the addresses are handled before building: inventory, pages not to break, redirects set before the switch, crawl diff after. The migration that starts with the design and ends with the redirects is the one that loses traffic.

Can I still edit my site myself? Yes. Either directly in the files, with an automatic preview and training, or in a headless CMS if several people publish. The choice is made at scoping, not by default.

Can a static site have a form, a search, a client area? Yes, each wired to a dedicated service: the forms on this site store every request in a database before sending the email, the internal search of a content site is built as an index at publication, and a client area is rendered server-side on the only pages that need it.

Why Astro rather than Next.js or another framework? Because a content site does not need an application. Astro produces HTML, sends JavaScript only where a component needs it, and reads content from any source. We have used it on our own sites since 2025: it is a choice proven in operation, not a fashion preference.