How to structure a static blog for good indexing
What actually matters in the technical structure of a content blog, and why the framework you pick weighs far less than most people assume.
There is a persistent belief that the choice of framework determines how a blog ranks. It is false. The search engine receives HTML and has no way of knowing what produced it.
What actually carries weight
Technical structure is a prerequisite, not an advantage. A slow or uncrawlable site is penalised, but a fast site earns no bonus points for being extra fast. Past the threshold, content is the differentiator.
In practice the order of importance is:
- Content that answers a real search intent
- Internal linking connecting articles on the same topic
- Core Web Vitals within the limits
- Structured data and crawlability
The common mistake is spending weeks on layer 3 and none on layer 1.
Core Web Vitals as a budget
Treat the metrics as a fixed budget, not a target to maximise:
| Metric | Limit | Project target |
|---|---|---|
| LCP | 2.5 s | 2.0 s |
| INP | 200 ms | 200 ms |
| CLS | 0.1 | 0.05 |
The margin exists because ads consume budget later.
Where structure genuinely helps
On a static site the HTML is already on disk when the request arrives. That removes an entire category of problems — no slow database, no cold start, no cache to invalidate.
The real gain is elsewhere: the marginal cost of publishing drops to nearly
zero. Writing a file and running git push is cheap enough that you publish
often, and frequency is what feeds layers 1 and 2.
npm run new "Article title"
npm run optimize
git commit -am "new article" && git pushIn short
Pick a foundation that stays out of the way, set the performance budget once, and get back to writing. Structure is infrastructure: when it is good, nobody notices it is there.