From Next.js to Astro: when a static site needs no SPA
A portfolio built as a client-side app indexes badly. Notes from the migration, the general advice, and what the switch gave me.
My portfolio was, for a long time, entirely a client-side Next.js application. In devtools it looked good; in search results considerably worse. This was my first migration to Astro, so what follows is a mix of what is generally recommended and what I ran into myself — but the decision is one I would make again.
The clearest test is to fetch your own page the way a crawler sees it. If the response contains an empty document body and everything else is rendered later by JavaScript, that is a fairly fundamental flaw in a site meant to bring people in from search.
The problem was not the framework, it was the rendering
Next.js can generate static pages; my portfolio used none of that — text, projects and translations were all assembled in the browser. Search engines do process JavaScript these days, but more slowly and less predictably. The rule I take from it: content that does not change between visits has no reason to need a runtime.
What the migration involved
- Content moved from TypeScript constants into a database and templates.
- Interactive parts — the contact form and the editor — as isolated islands.
- One URL per language instead of switching language at runtime.
The bulk of the work was not in the components but in that last point. A language switcher that only changes state behaves, from a crawler's point of view, as though the second language version did not exist.
If something has its own content, it should have its own address. That goes for languages just as much as for articles.
When I would not migrate
If it were an application behind a login. There most pages are unindexable anyway and the main benefit disappears. Astro makes sense where the content is mostly static and the interactive spots are few.
What it gave me
The page renders with practically no JavaScript, the blog has its own URLs and sitemap, and writing an article means opening the editor rather than making a commit. In hindsight it seems I originally picked the framework by what I knew best, not by what the site actually does.
Please take this as experience from a single site, not as a framework comparison. I can describe what changed for me — not claim it will turn out that way for everyone.
