Growing an Engineering Blog with SEO: What Actually Worked

When I relaunched this blog, my first few posts got almost no organic traffic. They were technically fine articles about ERP systems and DevOps tooling, but nobody was finding them, because I was writing for myself instead of writing for how people actually search. Over the following months I rebuilt the entire publishing pipeline around technical SEO: metadata generated per post, structured data injected at the layout level, a strict keyword template, and an internal linking system that connects every article to its neighbors.

This post is the honest version of what worked and what did not. It is not a generic SEO checklist copied from a marketing blog. It is the specific set of engineering decisions, in a Next dot js App Router codebase with next-intl for English and Indonesian, that turned a list of drafts into a site that ranks for long-tail engineering searches. I will walk through keyword strategy, the metadata layer, structured data, internal linking, and the metrics that actually mattered once real traffic showed up.

Long-tail keywords beat broad ones for a solo engineering blog

A brand new domain has no authority to compete for a broad term like devops or backend development. Those searches are dominated by sites with years of backlinks and huge content libraries. The realistic opportunity for an individual engineering blog is long-tail search, specific multi-word phrases with lower volume but far less competition and much higher intent. Someone searching for how to configure prometheus recording rules to reduce cardinality is closer to becoming a reader, or a client, than someone searching devops.

• Pick titles that name the exact tool, error, or workflow, not just the general category, so the title matches what a person actually typed into the search box.
• Write the primary keyword into the title, the meta description, and the first two paragraphs of the article, because that is where both readers and crawlers look first.
• Treat every keyword list as a template with twelve to fifteen long-tail phrases ending in your own name, so branded searches and topical searches both lead back to the same author identity.

Metadata and structured data are the technical foundation, not an afterthought

In a Next dot js App Router project, per-post SEO belongs in one place, a shared layout that every post inherits from, so nothing is duplicated across dozens of article components. The layout exports a generateMetadata function that reads a small metadata object per slug and returns the title, description, keywords, canonical URL, language alternates, and Open Graph fields for that exact post. Because generateMetadata runs on the server before the page renders, the resulting tags are already present in the initial HTML that search engines see, rather than being injected later by client-side JavaScript.

The same layout also renders JSON-LD structured data, a TechArticle or Article schema with author, publisher, and publish date, a BreadcrumbList schema so search engines understand the site hierarchy, and an FAQPage schema built from five question and answer pairs per post. Centralizing this in one layout file means adding a new blog post never means writing SEO code again, it means filling in data that an existing system already knows how to render.

export async function generateMetadata(
  { params }: { params: Promise<{ slug: string }> }
): Promise<Metadata> {
  const { slug } = await params;
  const meta = BLOG_META[slug];

  return {
    title: meta.title,
    description: meta.description,
    keywords: meta.keywords,
    alternates: {
      canonical: buildCanonical(slug),
      languages: buildLanguageAlternates(slug),
    },
    openGraph: {
      type: "article",
      title: meta.title,
      description: meta.description,
      images: [meta.image],
    },
  };
}

A repeatable process beats a one-off SEO push

SEO work that happens once and then gets forgotten decays fast. The only approach that compounds is a process every new post goes through automatically, so quality does not depend on remembering to do it manually each time. Here is the sequence that turned into a habit:

1. Research the long-tail keyword and competing pages first, before writing the outline, so the article is built around a real search query instead of a topic that merely sounds interesting.
2. Draft the title, meta description, and twelve to fifteen keyword phrases before the article body, and verify the character counts with a simple word count command rather than eyeballing it.
3. Write five FAQ question and answer pairs that mirror how real people phrase questions, what, why, how, can I, since these double as both structured data and natural subheadings readers scan for.
4. Add the new post to the category and related-posts system so it links to, and is linked from, other articles in the same topic area, instead of existing as an isolated page with zero internal links pointing to it.

What actually moved the needle, ranked by effort versus impact

Not every SEO tactic pays off equally. After several months of publishing, a rough pattern emerged across the tactics I tried, comparing the setup effort against the traffic impact once Google had fully indexed and re-crawled the site.

Internal linking turns isolated posts into a network

A single well-optimized post can rank, but a network of posts that link to each other with descriptive anchor text ranks more reliably, because it signals which pages the site itself considers most important and related. Google's own guidance on crawlable links states that every page you care about should have a link from at least one other page on the site, and that anchor text should be descriptive rather than a generic click here.

• Every blog post layout automatically renders a related-posts block, server-rendered with no client-side JavaScript, drawing from other posts in the same category.
• Anchor text inside article bodies names the actual tool or concept being linked to, for example a specific package name or configuration option, instead of vague phrases.
• Category pages act as topic hubs, so a reader arriving at any single Backend or DevOps post can browse sideways into the rest of that topic cluster without leaving the site.

The metrics that mattered, and the ones that were noise

Total pageviews felt satisfying to watch but told me almost nothing useful on their own. The metrics that actually explained what was working were: which exact queries in Search Console were driving impressions and clicks, which pages had high impressions but low click-through rate, meaning the title or description was not compelling enough for the ranking position, and which posts were gaining position over consecutive weeks after being freshly re-linked from a new article.

One thing worth being honest about, structured data itself is a moving target. Google has deprecated the FAQ rich result visual treatment in search results as of 2026, even though the underlying FAQPage schema remains valid structured data and is still worth including for other search engines and AI answer engines that do consume it. The lesson generalizes, build your SEO system around fundamentals that outlast any single rich-result feature, specifically keyword-matched titles, fast and correctly rendered metadata, and a genuinely interlinked site.