Tools · first published 2026-08-09 · updated 2026-08-09 · translated from the Finnish original

SEO, GEO and Three Web Architectures: What We Learned from Neuvottelija and DCM Capital

A field report from rebuilding www.neuvottelija.com and www.neuvottelija.fi on Cloudflare while keeping www.dcmcapital.fi on WordPress: what Astro changed, why agent readiness reached 100/100 and 93/100, and how Codex, Gemini and Claude now monitor search and generative-engine findability every week.

Sami Miettinen · Sections: Tools and Implementations + AI Research

The last article in this series ended with a perfect score. Claude built an English episode corpus, Gemini made domain discovery verifiable, and Codex repaired the protocol and retrieval plumbing. Cloudflare’s Agent Readiness benchmark returned 100/100 for Neuvottelija.com.

That was a useful milestone, but it was not the end of the work. A score is a snapshot of technical accessibility. SEO and GEO are operating systems: content changes, indexes lag, edge caches drift, analytics fill in retrospectively, and a technically perfect page can still fail to answer a question anyone asks.

The next phase therefore moved from one site and one benchmark to a portfolio experiment across three production websites:

This is not a race in which WordPress loses and Astro wins. It is a controlled comparison of what the same SEO and GEO principles look like in three different delivery models.

SEO and GEO solve different parts of findability

SEO makes a page legible to conventional search infrastructure: stable URLs, complete HTML, canonical links, hreflang, structured data, sitemaps, correct status codes and measurable indexing in Search Console.

GEO—generative-engine optimization—extends that contract to answer engines and software agents. The practical layer includes compact Markdown, llms.txt, structured JSON inventories, explicit crawler policy, source and date provenance, content negotiation, API discovery and machine-readable links between related resources.

Neither replaces the other. A Markdown mirror without a canonical page is weak publishing. A perfectly canonical page whose content only appears after a large JavaScript application runs is a weak retrieval surface. The portfolio work treats the human page, the search document and the agent representation as outputs from one source of truth.

What Astro changed on Neuvottelija.com

The decisive Astro advantage was not visual performance. It was build determinism.

An article enters a typed content collection. The build validates its frontmatter, then emits route-specific HTML, a Markdown mirror, JSON indexes, RSS and sitemap entries from the same source. The response already contains the article; JavaScript is optional enhancement. Cloudflare Pages receives the completed dist directory, while Pages Functions add content negotiation and discovery headers at the edge.

That design removed a whole class of ambiguity. A crawler does not need to execute React before it can identify the title, canonical URL or body. An agent can request Accept: text/markdown or follow the advertised Markdown link. An audit can compare HTML, Markdown, JSON and sitemap output and know they came from the same build.

The work also exposed how easy it is to reason about the wrong application in a monorepo. The Finnish AI article route is built by apps/ai-fi; the English route is built by apps/ai. Adding a Markdown file to a generic content/posts folder or adding a React route in another application cannot publish either page. The only reliable test is the build artifact itself:

apps/ai-fi/dist/tools/{slug}/index.html
apps/ai-fi/dist/tools/{slug}/index.md

apps/ai/dist/{slug}/index.html
apps/ai/dist/{slug}/index.md

The deployment lesson was equally concrete. The GitHub workflow builds each application from its own working directory and invokes Wrangler against the corresponding Cloudflare Pages project. A green build in the repository is necessary; it is not proof of what the edge serves. Production still needs live checks of the canonical page, Markdown mirror, machine index, response headers and cache state.

Why Neuvottelija.fi stopped at 93—and why that is respectable

Neuvottelija.fi did move to Cloudflare, but it did not become an Astro site. It remains a Vite/React application because it contains application behaviour and an established Finnish publishing workflow worth preserving.

The solution was to make its machine-critical surfaces static at build time. Episode and transcript shells, OpenClaw articles, metadata, sitemaps, Markdown documents and .well-known resources are written into the deployment before the React application hydrates. Cloudflare Pages serves those files directly and falls back to the SPA only where application routing is actually needed.

That hybrid reached 93/100. Its baseline was 57/100 when the site was a Lovable-hosted React SPA; the first stage of that journey is documented in From 57% to Agent-Native: How This Site Took Over www.neuvottelija.fi. The seven-point difference between 93 and a perfect score is informative: static-first Astro makes complete route-specific delivery the default, while the React site has to manufacture selected static guarantees around an application shell. But 93 is not a failed 100. It is evidence that an existing application can become substantially more discoverable without a high-risk rewrite.

Why DCM Capital deliberately stayed on WordPress

Most Neuvottelija subscribers and many advisory clients do not run Astro monorepos. They run WordPress. Removing WordPress from the experiment would have made the work less useful to them.

DCM Capital therefore remains the reference implementation for improving an older stack in place. A must-use WordPress plugin and a small web-root package now provide the agent-facing contract: llms.txt, auth.md, Markdown negotiation, OpenAPI, an API catalogue, agent skills, a public episode API and a complete local podcast sitemap connected to Yoast.

The performance work was just as important. Before caching, the homepage took roughly 7.1 seconds and parallel cold requests could produce HTTP 500 errors. With WP Super Cache in Expert mode, a one-hour expiry and an explicit warm-up request, the verified ten-request test returned 10/10 HTTP 200 in approximately 0.38–0.58 seconds.

WordPress imposes different constraints: plugin hooks can rewrite permalinks, PHP cold starts matter, caches must be warmed, and a generated endpoint can accidentally emit a heavy theme 404. But those are engineering constraints, not a reason to abandon the platform. The useful question is how much reliable findability can be added without forcing a client into a migration it does not need.

From the Valuatum cooperation to weekly measurement

The Valuatum cooperation sharpened the business requirement behind this work. A one-off technical audit was not enough. We needed a recurring view of whether changes improved discoverability, whether they merely moved metrics around, and whether a release had silently broken a machine-facing surface.

The resulting weekly system covers all three domains and keeps the evidence layers separate:

• Google Search Console for queries, pages, clicks, impressions, positions, indexing and URL inspection;
• GA4 and YouTube data for observed traffic and consumption, with bots and anomalies called out rather than relabelled as people;
• a fixed GEO query panel and append-only retrieval observations for provider-specific citation tests;
• endpoint checks for HTML, Markdown, JSON, sitemaps, feeds and agent discovery documents;
• a persistent workbook and Google Sheet containing the watchlist, change log, recommendations, run log, keywords and domain panels;
• raw per-run extracts and written handovers so a finding can be reproduced instead of disappearing into chat history.

The 9 August run illustrates why this matters. Portfolio search clicks rose 60 to 87 (+45%) week over week, and the Neuvottelija.fi brand query returned to position 1.1. All four English AI section pages were submitted and indexed after the preceding requests. At the same time, the run caught an inconsistent Cloudflare edge response serving an old index.json and an intermittent stale /openclaw/ page. The positive search trend did not cancel the infrastructure defect; both were recorded separately.

This is superior findability in the only defensible sense: more complete technical surfaces, measured indexing, stronger query performance and faster detection when production diverges from source. It is not a promise that a benchmark score causes traffic or that an LLM will cite a page.

Codex, Gemini and Claude as one operating loop

The models do not perform interchangeable jobs.

Claude runs the long-context weekly synthesis. It reads the accumulated memory and data extracts, separates observations from hypotheses, writes the report and updates the watchlist and recommendations.

Gemini receives operational handovers where Google-native context, DNS work or a bounded production investigation is useful. Its tasks have included DNSSEC and agent discovery, cache-remediation briefs and the next transcript-curation queue.

Codex works against the local repositories. It follows a finding down to routes, content schemas, build output, middleware and deployment configuration; implements the change; runs both Astro builds; commits and pushes; watches Cloudflare Pages deploy; and verifies the public URLs again.

Sami remains the approval gate. The models can research, compare and execute, but architectural intent—such as keeping DCM Capital on WordPress—is a business decision, not an optimization target to infer away.

The loop is simple:

measure → explain → hand off → change → build → deploy → verify → measure again

That loop is the continuation of the 100/100 story. The benchmark showed that an agent-native site could be built honestly. The portfolio work shows how to keep it honest—and how to transfer the same principles to a 93/100 hybrid and a deliberately conventional WordPress site.

Agent Readiness figures are dated benchmark snapshots, not traffic forecasts. Weekly-search figures come from the 9 August 2026 portfolio report and may be restated by Search Console. This article was drafted with Codex from the production repositories, weekly reports and handovers; Claude produced the recurring analysis, Gemini contributed operational work streams, and Sami Miettinen reviewed and approved the final text.

Markdown: index.md · Suomeksi