SEO Without a Plugin: How Static Sites Win at Search
Install WordPress. Install Yoast. Fill in the SEO title. Fill in the meta description. Check the green light. Publish.
That’s the SEO workflow most developers and content creators were trained on. A plugin that wraps your content in a dashboard panel, scores your keyword density, and injects the meta tags that search engines actually read. It works. Millions of sites run on it. And it teaches you absolutely nothing about what’s actually happening between your HTML and a search engine’s crawler.
Here’s the thing: every piece of SEO metadata that Yoast generates is just markup. It’s <meta> tags in your <head>. It’s JSON-LD in a <script> block. It’s an XML file at /sitemap.xml. There’s nothing proprietary about it. There’s no magic. There’s just structured data, written in formats that have public specifications, served as part of your HTML.
When you build a static site with Next.js, Astro, or any framework that gives you control over your HTML output, you don’t need a plugin to generate this markup. You generate it yourself — at build time, from your own content, with full control over every tag and every value. And because it’s generated at build time into static HTML, crawlers get it immediately without waiting for JavaScript to execute or a database to respond.
That’s the structural advantage. Let’s break it apart.
Meta Tags Are Just HTML
The foundation of on-page SEO is the <head> of your document. Title tag. Meta description. Canonical URL. Viewport. These are HTML elements that every page needs, and every framework gives you a way to set them.
In Next.js App Router, you export a metadata object or a generateMetadata function from your page:
// app/posts/[slug]/page.tsx
import { getPostBySlug } from "@/lib/posts";
export async function generateMetadata({ params }: { params: { slug: string } }) {
const post = await getPostBySlug(params.slug);
return {
title: post.title,
description: post.excerpt,
alternates: {
canonical: `https://yourdomain.com/posts/${params.slug}`,
},
};
}That’s it. Next.js takes this object and renders the corresponding <title>, <meta name="description">, and <link rel="canonical"> tags into the static HTML at build time. No plugin. No dashboard. No runtime dependency.
The canonical URL is worth calling out because it’s the tag most people forget. If your content is accessible at multiple URLs — with and without trailing slashes, with and without www, via pagination — the canonical tag tells search engines which version is the real one. Getting this wrong means splitting your ranking signals across duplicate URLs. Getting it right is a single line of metadata.
For non-Next.js frameworks, the pattern is the same. Astro has <head> access in layouts. Eleventy lets you inject head content through data cascade. Gatsby has gatsby-ssr.js. Every modern static site generator gives you deterministic control over the document head. Use it.
Open Graph: The Markup That Makes Links Look Good
When someone shares your article on LinkedIn, Twitter, Slack, or Discord, those platforms don’t render your page. They read your Open Graph tags and build a preview card from them. If you don’t have Open Graph tags, you get a bare URL. If you do, you get an image, a title, and a description — the difference between someone clicking through and someone scrolling past.
Open Graph is a set of <meta> tags with a property attribute instead of name:
<meta property="og:title" content="SEO Without a Plugin" />
<meta property="og:description" content="How static sites win at search." />
<meta property="og:image" content="https://yourdomain.com/media/seo-article-hero.webp" />
<meta property="og:url" content="https://yourdomain.com/posts/seo-without-a-plugin" />
<meta property="og:type" content="article" />
<meta property="og:site_name" content="Static Signal" />Twitter (X) has its own variant with twitter:card, twitter:title, and twitter:image tags. In practice, most platforms fall back to Open Graph if Twitter-specific tags aren’t present, but setting both ensures consistent previews everywhere.
In Next.js, you add these to your metadata object:
export async function generateMetadata({ params }: { params: { slug: string } }) {
const post = await getPostBySlug(params.slug);
const ogImage = `https://yourdomain.com/media/${post.heroImage}`;
return {
title: post.title,
description: post.excerpt,
alternates: {
canonical: `https://yourdomain.com/posts/${params.slug}`,
},
openGraph: {
title: post.title,
description: post.excerpt,
url: `https://yourdomain.com/posts/${params.slug}`,
siteName: "Static Signal",
images: [{ url: ogImage, width: 1200, height: 630 }],
type: "article",
publishedTime: post.publishedAt,
},
twitter: {
card: "summary_large_image",
title: post.title,
description: post.excerpt,
images: [ogImage],
},
};
}Every blog post on your site now generates a full set of social preview tags from its own frontmatter. The hero image you already have becomes your OG image. The excerpt you already wrote becomes your OG description. No manual entry in a plugin sidebar. No forgetting to fill in the Twitter card fields. The build process handles it because the data already exists in your content.
The 1200x630 pixel dimension for OG images is the safe zone. LinkedIn, Facebook, and Twitter all render this size well. If your hero images are a different aspect ratio, consider generating a cropped variant at build time or using a service like @vercel/og to dynamically compose them.
Structured Data: Speaking the Crawler’s Language
Meta tags tell search engines about your page. Structured data tells them what your page is. It’s the difference between “this page has a title and description” and “this page is a blog post, written by this author, published on this date, in this category.”
Structured data uses the Schema.org vocabulary, encoded as JSON-LD in a <script> tag. Google reads this and uses it to generate rich results — the enhanced search listings with star ratings, FAQ accordions, breadcrumbs, and article metadata that take up more visual space in the SERP.
For a blog post, the relevant schema type is Article or BlogPosting:
function generateArticleSchema(post: Post) {
return {
"@context": "https://schema.org",
"@type": "BlogPosting",
headline: post.title,
description: post.excerpt,
image: `https://yourdomain.com/media/${post.heroImage}`,
datePublished: post.publishedAt,
dateModified: post.updatedAt || post.publishedAt,
author: {
"@type": "Person",
name: post.author,
url: "https://yourdomain.com/about",
},
publisher: {
"@type": "Organization",
name: "Static Signal",
url: "https://yourdomain.com",
logo: {
"@type": "ImageObject",
url: "https://yourdomain.com/logo.png",
},
},
mainEntityOfPage: {
"@type": "WebPage",
"@id": `https://yourdomain.com/posts/${post.slug}`,
},
};
}You drop this into your page layout as a <script type="application/ld+json"> block:
<script
type="application/ld+json"
dangerouslySetInnerHTML={{
__html: JSON.stringify(generateArticleSchema(post)),
}}
/>Once it’s in your layout, every blog post on the site gets valid structured data automatically. You can verify it with Google’s Rich Results Test — paste your URL, and it shows you exactly what Google can extract.
The payoff isn’t just rich results. Structured data helps Google understand the relationships between your content. When your articles have author, datePublished, articleSection, and keywords fields, you’re giving the crawler a machine-readable map of your content that’s more precise than anything it could infer from the HTML alone.
You can extend this pattern to other page types. Your homepage gets WebSite schema with a SearchAction for sitelinks search. Your about page gets Person or Organization schema. Your category pages get CollectionPage. Each schema type is a signal that helps search engines categorize and present your content correctly.
Sitemaps: The Index Card for Crawlers
A sitemap is an XML file that lists every page on your site that you want search engines to index. It includes the URL, the last modification date, and optionally a priority and change frequency. Crawlers use it to discover pages they might not find through link-following alone, and to understand which pages have been updated since the last crawl.
For a static site, generating a sitemap is a build step. You already know every page that exists — it’s your content directory plus your static routes. You loop over them and output XML:
// scripts/generate-sitemap.ts
import { glob } from "node:fs/promises";
import { writeFile } from "node:fs/promises";
import path from "node:path";
async function generateSitemap() {
const baseUrl = "https://yourdomain.com";
const posts: string[] = [];
for await (const file of glob("content/posts/*.md")) {
const slug = path.parse(file).name;
posts.push(slug);
}
const staticPages = ["", "about", "categories"];
const urls = [
...staticPages.map((page) => ({
loc: `${baseUrl}/${page}`,
changefreq: "weekly",
})),
...posts.map((slug) => ({
loc: `${baseUrl}/posts/${slug}`,
changefreq: "monthly",
})),
];
const xml = `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
${urls
.map(
(url) => ` <url>
<loc>${url.loc}</loc>
<changefreq>${url.changefreq}</changefreq>
</url>`
)
.join("\n")}
</urlset>`;
await writeFile("public/sitemap.xml", xml);
}
generateSitemap();Run this as a postbuild script and your sitemap is always in sync with your content. No plugin that queries a database. No cron job that regenerates periodically. The sitemap is a build artifact, produced from the same source of truth as the site itself.
Next.js App Router also supports a sitemap.ts file that exports a function, generating the sitemap as part of the build. Either approach works — the choice depends on whether you prefer a standalone script or framework integration.
Submit your sitemap URL to Google Search Console and Bing Webmaster Tools. Once submitted, you can monitor which pages are indexed, which have errors, and which are being ignored. This feedback loop is more valuable than any plugin dashboard because it’s the actual indexer telling you what it found.
RSS: The Feed That Keeps Working
RSS feels like a relic of the 2000s blogosphere, but it’s quietly essential for SEO and content distribution. Podcast apps, feed readers, news aggregators, and automated workflows all consume RSS. Some search engines use RSS feeds to discover new content faster than they would through crawling alone.
An RSS feed is an XML file that describes your recent content:
// scripts/generate-rss.ts
import { readFile, writeFile } from "node:fs/promises";
import { glob } from "node:fs/promises";
import path from "node:path";
import matter from "gray-matter";
async function generateRSS() {
const baseUrl = "https://yourdomain.com";
const posts: Array<{ title: string; slug: string; excerpt: string; date: string }> = [];
for await (const file of glob("content/posts/*.md")) {
const content = await readFile(file, "utf-8");
const { data } = matter(content);
if (!data.draft) {
posts.push({
title: data.title,
slug: data.slug || path.parse(file).name,
excerpt: data.excerpt,
date: new Date(data.publishedAt).toUTCString(),
});
}
}
posts.sort((a, b) => new Date(b.date).getTime() - new Date(a.date).getTime());
const xml = `<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Static Signal</title>
<link>${baseUrl}</link>
<description>Cutting through the noise in modern web development.</description>
<atom:link href="${baseUrl}/rss.xml" rel="self" type="application/rss+xml"/>
<language>en-us</language>
${posts
.slice(0, 20)
.map(
(post) => ` <item>
<title><![CDATA[${post.title}]]></title>
<link>${baseUrl}/posts/${post.slug}</link>
<guid isPermaLink="true">${baseUrl}/posts/${post.slug}</guid>
<description><![CDATA[${post.excerpt}]]></description>
<pubDate>${post.date}</pubDate>
</item>`
)
.join("\n")}
</channel>
</rss>`;
await writeFile("public/rss.xml", xml);
}
generateRSS();Link to the feed in your document head so autodiscovery works:
<link rel="alternate" type="application/rss+xml" title="Static Signal" href="/rss.xml" />Now anyone with a feed reader can subscribe. Automated pipelines can pick up your content. And search engines have another signal that your site is actively publishing.
robots.txt: The One File Everyone Forgets
Your robots.txt tells crawlers what they should and shouldn’t index. For most static sites, it’s simple:
User-agent: *
Allow: /
Disallow: /api/
Sitemap: https://yourdomain.com/sitemap.xmlThe Sitemap directive at the bottom is how crawlers discover your sitemap without you needing to manually submit it. Some crawlers check robots.txt first and follow the sitemap link automatically.
Drop this in your public/ directory and it deploys with the rest of your static assets. It never changes unless your URL structure changes. In WordPress, robots.txt is dynamically generated and can be modified by any plugin — which means you sometimes find out that a misconfigured SEO plugin has been telling Google to ignore half your site. With a static file, what you write is what gets served.
The Performance Advantage Is an SEO Advantage
Everything we’ve covered so far is about explicit metadata — telling search engines what your content is and where to find it. But there’s a second dimension to SEO that static sites win by default: performance.
Google uses Core Web Vitals as ranking signals. LCP, INP, and CLS directly affect where your pages appear in search results. A static site that serves pre-rendered HTML from a CDN edge node has a structural advantage over a dynamic site that renders on the server for every request.
Your Time to First Byte is the CDN’s cache response time — usually under 50ms from the nearest edge. Your LCP is whatever your largest above-the-fold element is, served immediately in the HTML without waiting for a database query, a server render, or a JavaScript hydration pass. Your CLS is zero if your layout is stable, which it tends to be when there’s no dynamic content insertion happening after load.
This isn’t a hypothetical edge. For content-heavy sites — blogs, documentation, marketing pages — the performance gap between static and dynamic is measurable in Core Web Vitals data and visible in search rankings. Two sites with identical content and identical backlink profiles will rank differently if one loads in 1.2 seconds and the other in 3.8 seconds.
You don’t get this advantage by installing a caching plugin on top of a dynamic CMS. You get it by not having the dynamic layer in the first place.
The Complete SEO Stack for a Static Site
Here’s everything your static site needs for competitive SEO, with zero runtime dependencies:
Per-page metadata — title, description, canonical URL, generated from your content’s frontmatter at build time.
Open Graph and Twitter cards — social preview tags generated from the same frontmatter, ensuring every share has an image, title, and description.
JSON-LD structured data — BlogPosting schema for articles, WebSite schema for your homepage, Person or Organization schema for your about page. All generated from your content data at build time.
XML sitemap — generated as a build artifact from your content directory and static routes. Submitted to Search Console, referenced in robots.txt.
RSS feed — generated from your published posts at build time. Linked in your document head for autodiscovery.
robots.txt — a static file in your public/ directory with a sitemap reference.
Performance — pre-rendered HTML served from a CDN, delivering sub-second LCP and passing Core Web Vitals by default.
Every item on this list is either a build-time generation step or a static file. None of them require a database query at request time. None of them require a plugin that needs updates. None of them require a configuration dashboard that you have to remember to fill in.
The data that drives all of this already exists in your content. Your frontmatter has the title, excerpt, author, date, and image. Your file system has the URL structure. The build process connects the two and outputs the markup that search engines consume.
Why Plugins Exist (and When You Might Still Want One)
Yoast and RankMath exist because WordPress doesn’t generate this markup by default, and most WordPress users don’t write code. The plugins abstract away the HTML. That’s a legitimate service for that audience.
But if you’re building with a modern framework — if you’re writing React components, TypeScript functions, and build scripts — you don’t need that abstraction. You’re closer to the HTML than any plugin can get you. The abstraction layer is a ceiling, not a floor.
The one place where SEO tooling still adds value beyond markup generation is analysis. Tools that crawl your site and check for broken links, missing alt text, orphaned pages, redirect chains, and thin content are genuinely useful as auditing tools. Screaming Frog, Ahrefs, and Google Search Console itself provide this kind of structural analysis. That’s a different problem than metadata generation, and it’s worth separating the two in your head.
Generate your markup yourself. Audit with external tools. That split gives you full control over your output and expert analysis of its effectiveness — without a plugin sitting between you and your HTML.
The Build-Time Advantage
Every SEO optimization for a static site happens before the first request arrives. By the time a crawler hits your URL, the metadata is baked in, the structured data is in the HTML, the sitemap is at a known path, and the page loads in under a second.
There’s no plugin to misconfigure. No caching layer to invalidate. No database query to slow down. No JavaScript that needs to execute before the meta tags appear in the DOM.
Search engines get what they see. And what they see is exactly what you built.
That’s the argument for static SEO. Not that plugins are bad — they’re fine for what they do. But they solve a problem that doesn’t exist when you control the HTML. And controlling the HTML is the entire point of building a static site.
Static Signal is published by Neuron Web Development.