![[Frontend Architecture] SEO Design](/uploads/2026/04/arch-intro-cat-frontend.png)
About this article
As the eighth installment of the “Frontend Architecture” category in the series “Architecture Crash Course for the Generative-AI Era,” this article explains SEO (Search Engine Optimization).
The rendering method, URL design, and metadata strategy are decided at the architecture-selection stage and are an area you cannot bolt on later. This article presents guidelines for building these in at initial design - covering the relationship between rendering and SEO, meta tags, OG images, structured data (JSON-LD), sitemaps, URL design, i18n, and Core Web Vitals.
Before you read this
This article is mostly about how the browser side — the screen — works. If IT vocabulary is unfamiliar, reading the primers "How a Web Service Works" and "Programs and APIs" first makes it far easier to follow. You can also look anything up in the glossary as you read.
What is SEO design in the first place
SEO design is, roughly speaking, “building the technical foundation so search engines correctly understand your site’s content and rank it higher in search results.”
Imagine how you display a restaurant sign. No matter how good the food, if the sign is unreadable, the place isn’t on the map, and the entrance is unclear — customers won’t come. SEO design is the work of preparing a website’s “sign, map, and entrance” for search engines, and elements like rendering method, meta tags, structured data, and URL design are decided at the architecture-selection stage and cannot be bolted on later.
Why SEO design is needed
The choice of rendering method decides the SEO. CSR-only SPAs may fail to let search engines correctly capture content. SSR, SSG, and ISR choice directly impacts SEO, and changing later is a major undertaking.
Technical SEO is settled at the architecture stage. URL design, canonical settings, structured data, OG tags — regardless of content quality, technical design mistakes lower search rankings. The tech foundation must be set before content SEO.
Retrofitting SEO costs ten times more. Even if you notice “SEO is weak” after development is done, changing the rendering method means redesigning from scratch. Building it in from the start is overwhelmingly cheaper.
Google’s algorithm evolves year over year toward favoring sites with good user experience. Slow, mobile-unfriendly, accessibility-deficient sites won’t rank highly even with good content. SEO is a combined battle of content, performance, accessibility, and structured data - the foundation for advertising-free traffic acquisition.
SEO cannot be bolted on later. It’s decided at architecture-selection time.
SEO and rendering
Choice of rendering method has a direct hit on SEO. Whether content is readable in the HTML state determines crawler comprehension.
| Method | SEO | Reason |
|---|---|---|
| SSR / SSG | Excellent | Search engines can read HTML directly |
| CSR | Marginal | JS execution required, interpreted but delayed |
| Dynamic Rendering | Good | Compromise that SSRs only for bots |
Even with CSR, the Google crawler reads HTML after JS execution, so it’s recognized technically. But because execution timing is delayed by days to weeks, it’s a major disadvantage for sites where freshness matters. The conclusion is that for serious SEO, SSG / SSR is the rule.
If SEO is required, SSG or SSR. Fighting with CSR is at a disadvantage.
Meta tags, Open Graph and structured data
Meta tags inside <head> are the first step in conveying page info to search engines. No matter how high-performance the FW, if these are sloppy, SEO doesn’t even start.
<head>
<title>Article title | Site name</title>
<meta name="description" content="Page summary within 120 chars">
<link rel="canonical" href="https://example.com/post/1">
<meta name="robots" content="index, follow">
</head>Design principles:
- title and description must be unique per page (same across all pages is fatal)
- Unify duplicate URLs with canonical (trailing-slash issues etc.)
- Make index/noindex explicit with robots
Mechanisms for consistently managing meta tags as components are standard in FWs - Next.js’s metadata API, Astro’s <SEO> component. There’s no reason not to use them.
Open Graph and Twitter Cards govern how a link looks when it is shared.
Open Graph (OG, the standard for SNS share-preview control) and Twitter Cards are meta tags that control preview images, titles, and descriptions on SNS shares. On sites with high SNS traffic, OG quality moves CTR by several times.
<meta property="og:title" content="Article title">
<meta property="og:description" content="Summary">
<meta property="og:image" content="https://example.com/og.png">
<meta property="og:type" content="article">
<meta name="twitter:card" content="summary_large_image">The standard image size is 1200 x 630px. Almost the same size displays appropriately on major SNS. Manually creating one each time is unrealistic, so building in a “title-to-OG-image auto-generation” mechanism (Next.js ImageResponse, Vercel OG Image, CDN transform APIs) makes operations dramatically easier.
OG images go auto-generated. Manual production becomes a bottleneck and missed SNS-traffic opportunity.
Structured data (JSON-LD) is the third layer.
Structured data is the meta information needed for Google to show rich snippets (star ratings, prices, FAQs, event info) in search results. Written in <script type="application/ld+json"> using schema.org vocabulary.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Article title",
"author": { "@type": "Person", "name": "Author" },
"datePublished": "2026-04-18"
}
</script>Representative examples are Article / Product / FAQ / BreadcrumbList / Organization / Recipe. Putting these in stands out visually in search results, with CTR going one rank higher.
sitemap.xml and robots.txt sit alongside it.
sitemap.xml and robots.txt are files telling search engines “which pages to read and which not to read.” Both are placed at the site root.
| File | Role |
|---|---|
| sitemap.xml | All-URL list, crawl hint to search engines |
| robots.txt | Crawl-permission instructions, exclusion targets |
# robots.txt
User-agent: *
Allow: /
Disallow: /admin/
Sitemap: https://example.com/sitemap.xmlNext.js and Astro have auto-generation plugins. Hand-writing matches reality only on the first attempt and quickly diverges, so plugin automation is required. Manual operation is guaranteed to break down.
For sitemap/robots, leave it to the framework’s auto-generation. Hand-writing is a landmine.
URL design and i18n
URLs matter for both SEO and UX. URLs that humans can read and understand is the rule, and search engines also use words contained in URLs as a ranking factor.
✅ /blog/how-to-use-astro
✅ /products/thinkpad-x1-carbon
❌ /blog.php?id=42
❌ /products?itemId=sku123&var=xDesign principles:
- Include meaningful words (content can be inferred from URL)
- Lowercase, hyphen-separated (hyphens over underscores)
- Encoded Japanese URLs are tolerated, but alphanumeric is preferred
- Hierarchy up to 2-3 levels (too deep is unfavorable for both SEO and UX)
URLs are an element hard to change once published. It’s worth taking time on initial design. When unavoidable, guide from old URLs with 301 redirects.
Internationalisation is where URL design and SEO meet head-on.
For multilingual sites, the URL composition per language and hreflang design decide SEO success. Get it wrong and Google sees it as duplicate identical content and rankings fall.
| Method | Example | Characteristics |
|---|---|---|
| Subdirectory | /en/about /ja/about | Easy to manage on one domain |
| Subdomain | en.example.com / ja.example.com | Independent management per language |
| Separate domain | example.com / example.jp | Separated by country/brand |
hreflang makes the per-language correspondence explicit. Without it, you get misjudged as “same content on multiple pages.”
<link rel="alternate" hreflang="en" href="https://example.com/en">
<link rel="alternate" hreflang="ja" href="https://example.com/ja">This project (senkohome.com) adopts the subdomain method (senkohome.com / en.senkohome.com).
Core Web Vitals are the last piece of technical SEO.
Core Web Vitals is Google’s defined trio of perceived-speed metrics, with direct impact on search rankings. An operation that periodically checks them with measurement tools (PageSpeed Insights / Lighthouse / Search Console) is required.
| Metric | Meaning | Target |
|---|---|---|
| LCP (Largest Contentful Paint) | Time until largest content is rendered | < 2.5 sec |
| INP (Interaction to Next Paint) | Interaction responsiveness | < 200 ms |
| CLS (Cumulative Layout Shift) | Layout shift | < 0.1 |
Improvements: image optimization (WebP/AVIF), font optimization (preload/subset), JS bundle reduction (code splitting, drop unneeded deps), specifying image size attributes to prevent CLS. Not a one-shot fix - continuous monitoring is the operational premise.
Real-world measurement data is available in Google Search Console. Build periodic checks into operations.
How to operate it — the SEO numeric gates
Note: Industry baseline values as of April 2026. Will become outdated as technology and the talent market shift, so requires periodic updates.
SEO is measurable. Following numbers makes vague debates disappear. Below are industry-standard targets.
| Metric | Recommended | Verification tool |
|---|---|---|
| Lighthouse Performance | 90 or more | Lighthouse / PageSpeed Insights |
| Lighthouse SEO | 90 or more | Lighthouse |
| Lighthouse Accessibility | 90 or more | Lighthouse / axe-core |
| LCP | < 2.5 sec | PageSpeed Insights |
| INP | < 200 ms | Search Console |
| CLS | < 0.1 | PageSpeed Insights |
| Image alt attributes | 100% set | axe-core |
| Structured data errors | 0 | Google Rich Results Test |
| title/description uniqueness rate | 100% | Search Console coverage |
| canonical tag setting rate | 100% | Search Console |
The state where “pages remain that score below 90 on Lighthouse SEO” is evidence of basic omissions. Ensure each page has unique title/description/canonical, and an operation of weekly Search Console check-ins.
Measure weekly with Lighthouse / Search Console. Numbers-driven operation is the modern norm.
Three scenarios
If you are building solo or at a startup
Simply riding on SSG in Astro or Next.js settles about eighty percent of technical SEO. Meta tags, Open Graph, the sitemap and structured data are all generated automatically by the framework’s standard features, so the human should concentrate on what makes the content distinctive. One thing to do on day one, though: register with Search Console.
If you are a small or mid-size SaaS
This is the stage for serving the acquisition pages — landing pages, blog, feature descriptions — from ISR or SSG, and establishing weekly monitoring of Core Web Vitals. If SEO drives revenue directly, it is well worth going as far as wiring Lighthouse CI into the pipeline so that a deploy is blocked when the score degrades.
If you are a large enterprise
Structural management across multiple domains, multiple languages and large page counts becomes the real subject. Getting hreflang, canonical or the redirect design for a site move wrong loses years of accumulated search equity, so put a joint review process between a dedicated SEO specialist and the engineers in place.
AI decision axes — Technical SEO to the AI, originality to the human
SEO metadata generation is an area AI handles accurately
Generating title, description, OG tags, and JSON-LD structured data is AI’s forte. When written following Next.js’s metadata API or Astro’s SEO component format, accurate metadata outputs without syntax errors. However, the core of SEO - “content quality, originality, E-E-A-T” - is an area humans must guarantee.
AI mass-produced articles and SEO
Since 2024, Google has clarified its policy of evaluating AI-generated content by “quality” not “creation method.” However, AI mass-produced articles without first-hand info or original experience can’t differentiate from other mass-produced articles and rankings don’t rise. When SEO matters, the effective division of labor is: AI handles structure, metadata, and technical SEO optimization; humans guarantee content originality.
Pitfalls and forbidden moves
Here are the six most dangerous causes of a collapse in search traffic.
| Forbidden move | Why it is bad → what to do instead |
|---|---|
The same title and description on every page | duplicate detection cuts indexing sharply → make them unique per article |
| No canonical tag | URL variants scatter the SEO signal → set one on every page |
| Building an SEO-critical site with CSR only | the crawler’s JavaScript execution lags by weeks → use SSG or SSR |
| Changing URLs without 301 redirects | the SEO signal resets → always send the old URL on with a 301 |
| Rolling out multiple languages with no hreflang | it is treated as duplicate content → state the per-language correspondence explicitly |
| Not putting Core Web Vitals measurement into operation | degradation goes unnoticed and rankings slide → build weekly measurement in |
Author’s note — the case of “every page had the same title” sinking a site
There’s a story about a small media site where 200+ articles all had <title> set to just the site name. Checking Search Console showed only a dozen articles indexed. With no per-article identifier, Google was treating them as duplicate pages.
After putting unique title/description on each article and tidying up canonicals, search traffic grew more than 10x in a few months. Conversely, “they were losing 90%+ of traffic opportunity by missing the basics of basics” up to that point.
I made similar mistakes on my personal blog, and from the month after I started putting unique per-page metadata via Astro’s <SEO> component, click rates clearly changed. SEO is an area “evaluated where you can’t see it” - any corner-cutting silently piles up losses. Tracking by numbers makes vague debate disappear and improvement cycles turn.
For SEO, don’t fight by “feel.” Measurement and unique metadata are 90%.
What to decide - what is your project’s answer?
For each of the following, try to articulate your project’s answer in 1-2 sentences. Starting work with these vague always invites later questions like “why did we decide this again?”
- Rendering method (from an SEO standpoint)
- Metadata standard (title/description/OG)
- sitemap/robots generation method (auto-plugin)
- Scope of structured-data adoption
- URL design convention
- i18n method (subdirectory / subdomain / separate domain)
- Core Web Vitals measurement loop (weekly Lighthouse)
For frontend security settings (CSP, dependency monitoring, etc.), refer to the previous “Auth” article and the security chapter.
Related Articles
Summary
This article covered SEO, including rendering, meta tags, OG image auto-generation, structured data, sitemaps, URL design, i18n, and Core Web Vitals.
SEO is mostly decided at initial design. Base on SSG/SSR, automate the mechanical parts via framework standards, and have humans guarantee originality. That is the practical answer for frontend SEO design in 2026.
Next time we’ll start a new category (Data Architecture).
Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book
I hope you’ll read the next article as well.
Also popular with readers
📚 Series: Architecture Crash Course for the Generative-AI Era (44/95)