DEV Community: Yusufhan Sacak

Designing an AI-Native Content Publishing Pipeline

Yusufhan Sacak — Sat, 14 Mar 2026 07:31:30 +0000

Over the past few weeks I've been working on a content hosting system that allows AI tools to publish structured artefacts directly into a production environment.

The goal was simple:

Make it possible to generate and publish structured content using AI — without developers being in the loop.

Today tools like Claude or GPT are excellent at generating content, but they usually stop at the generation step.

Publishing is still manual.

Someone still needs to move the generated content into a CMS, format it, upload assets, and press publish.

What we wanted instead was a pipeline where an AI assistant could generate an artefact and publish it directly to a hosting system in a controlled way.

The Core Idea

Instead of thinking in terms of:


CMS → editor → publish

we flipped the model.

The system is built around artefacts.

An artefact can be:

a document
a presentation
a template
structured HTML content
any renderable asset

The pipeline then becomes:


AI Tool
↓
MCP Tool Call
↓
Content API
↓
Artefact Storage
↓
Public Rendering Endpoint

This allows AI tools to generate something and immediately turn it into a hosted resource.

Instead of manually moving content through several systems, publishing becomes an infrastructure action.

System Components

The architecture consists of three primary layers.

1. Publishing UI

A simple frontend interface for manual publishing and inspection.

Its responsibilities are:

viewing artefacts
uploading templates
triggering publish actions
previewing output

This is mainly used when humans want to inspect or manage artefacts directly.

2. Content API

The API layer acts as the control plane for publishing.

It handles:

artefact creation
validation
storage
access control
rendering metadata

The API intentionally avoids exposing infrastructure details. Instead it provides a small set of safe publishing primitives that external systems can call without needing to understand the underlying storage or rendering layer.

One important design choice was making the system API-first.

Publishing is ultimately just an HTTP request.

Because of this, any external system capable of sending an HTTP request can use the pipeline.

3. Public Rendering Layer

The rendering layer takes stored artefacts and serves them through public endpoints.

Each artefact gets a unique URL that can be shared, embedded, or referenced from any external system.

Automation and External Integrations

Making publishing API-driven turned out to be extremely useful.

It means the system can easily integrate with external tools and automation platforms.

For example, automation systems like Workato can trigger publishing as part of a workflow.

A typical flow might look like:


CRM Event
↓
Automation Recipe
↓
HTTP Request to Content API
↓
Artefact Created
↓
Public URL Generated

Instead of manually creating documents or presentations, the automation system can generate and publish them automatically.

This makes the content pipeline usable not only by humans, but by systems.

MCP Integration

The most interesting part is the MCP interface.

This allows AI tools to interact with the content system as if it were a native tool.

Example interaction:


User: Publish this presentation using the standard template.

The assistant then calls the MCP tool, which forwards the request to the content API.

From the user's perspective the workflow becomes:


Prompt → Published Artefact

No manual publishing step is required.

Why MCP Matters

Without tool interfaces like MCP, AI tools are mostly isolated.

They can generate text, but they cannot safely interact with external systems.

MCP exposes infrastructure as capabilities.

Instead of telling an assistant:

Write a presentation.

you can say:

Publish this presentation.

And the assistant can actually perform the action.

Artefacts Instead of Pages

One design decision that simplified the system was avoiding the concept of pages.

Pages are tied to websites.

Artefacts are portable outputs.

An artefact can be:

rendered on a webpage
embedded in a CRM
attached to an email
inserted into a presentation
accessed via API

This abstraction keeps the publishing layer flexible and independent from any single frontend.

Safety Considerations

Allowing external systems — especially AI tools — to publish content introduces obvious risks.

A few constraints help keep the system safe:

strict template boundaries to prevent arbitrary content injection
sanitised HTML rendering to block malicious payloads
isolated hosting layer so publishing cannot affect other infrastructure
controlled publishing endpoints with authentication and rate limiting

The goal is to allow fast publishing without turning the system into an open execution environment.

Where This Is Going

AI tools are slowly evolving from chat interfaces into interfaces for systems.

Content platforms, automation pipelines, deployment systems, and internal tools are starting to expose structured interfaces that AI can operate.

Publishing is just one example.

But it illustrates a broader shift: AI tools moving from generating information to triggering real infrastructure actions.

The workflow becomes:


Prompt
↓
Tool Call
↓
Infrastructure Action
↓
Published Output

Things that previously required multiple manual steps can now happen in seconds.

Originally published on my personal site:

https://yusufhan.dev/blog/designing-an-ai-native-content-publishing-pipeline

Why Google Isn't Indexing Your Next.js Site (And How to Find Out in 3 Seconds)

Yusufhan Sacak — Wed, 18 Feb 2026 19:45:52 +0000

You've spent weeks building your Next.js site. You've deployed to Vercel. Everything looks beautiful. There's just one problem — Google doesn't seem to know your site exists.

You check Search Console. It says "Discovered – currently not indexed" on half your pages. Some pages have "Crawled – currently not indexed" with zero explanation. You Google your own brand name and get nothing.

Sound familiar? You're not alone. I've been there, and honestly, it drove me mad.

The silent killers nobody warns you about

Here's what most Next.js tutorials won't tell you: there are at least a dozen ways your perfectly working site can be completely invisible to search engines. And the worst part? None of them show any visible symptoms in your browser.

The 308 trap. Set trailingSlash: true in your next.config.js and Next.js starts returning 308 permanent redirects. Googlebot follows redirects, but chains of them waste your crawl budget. I've seen sites where a single page visit triggered 3 redirects before landing — that's crawl budget down the drain.

The middleware ghost. Next.js middleware can rewrite URLs, redirect users, or modify headers. The problem? It often only affects bots, not browsers. So you test your site, everything works, but Googlebot is getting served something completely different.

The canonical mismatch. Your page lives at https://example.com but the canonical tag points to https://www.example.com. You've just told Google to ignore half your site.

The missing robots.txt. No robots.txt means no sitemap directive, no crawl guidance, nothing. Google will figure it out eventually, but "eventually" could be months.

These aren't edge cases. They're incredibly common on Next.js/Vercel deployments. I kept running into the same issues across different projects, so I built a tool to catch them all in one go.

Introducing vercel-seo-audit

npx vercel-seo-audit https://your-site.com

That's it. One command. It takes about 2-3 seconds and tells you exactly what's wrong, why it matters, and how to fix it.

Here's what the output actually looks like:

SEO Audit Report for https://example.com/
  Completed in 1483ms

  Summary:
    ✖ 1 error
    ⚠ 3 warnings
    ℹ 2 info
    ✔ 4 passed

  REDIRECTS
  ────────────────────────────────────────
  ✖ [ERROR] Redirect chain detected (3 hops)
    → Reduce to a single redirect: http://example.com → https://example.com/

  METADATA
  ────────────────────────────────────────
  ⚠ [WARNING] Canonical URL mismatch
    → Canonical points to https://www.example.com/ but page is https://example.com/

Every finding comes with three things: what's wrong, why it matters for SEO, and a concrete suggestion to fix it. No vague "something might be off" messages.

What it actually checks

The tool runs 11 audit modules in parallel. Here's the full list:

The basics that everyone forgets:

robots.txt — missing, blocking Googlebot, missing Sitemap directive
sitemap.xml — missing, redirected, empty, broken URLs, robots.txt cross-check
Favicon — missing entirely, missing HTML link tags, conflicting declarations

The metadata that makes or breaks your rankings:

Canonical URL presence and mismatches
noindex directives (both meta tags and X-Robots-Tag headers — yes, they can exist in headers too)
Missing title, description, charset, viewport
Open Graph tags (og:title, og:description, og:image) with broken image detection
Twitter Card validation (twitter:card, twitter:image)

The Next.js/Vercel-specific gotchas:

Trailing slash 308 redirect traps
Middleware rewrite/redirect detection
Vercel deployment fingerprinting

The stuff that separates good SEO from great:

Structured data / JSON-LD validation (checks for Article, FAQPage, Product, Organisation and more)
Internationalisation / hreflang tags (self-reference, x-default, reciprocal links)
Image SEO (missing alt text, not using next/image, missing lazy loading, oversized images, layout shift)
Security headers (HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy)

And with --crawl, it fetches every URL from your sitemap and audits each page individually.

Real-world examples

Let me show you what this looks like on actual sites.

A well-configured site

Running it against a properly configured Next.js portfolio site:

Summary:
  ⚠ 1 warning
  ℹ 3 info
  ✔ 3 passed

One warning about missing width/height on some images, a few informational notes. Basically healthy.

A site with problems

Running it against a site that hadn't thought about SEO:

Summary:
  ⚠ 4 warnings
  ℹ 8 info

  ROBOTS — robots.txt not found
  SITEMAP — sitemap.xml not found
  METADATA — Canonical URL missing, og:image missing
  TWITTER — twitter:card missing
  SECURITY — HSTS missing, X-Content-Type-Options missing
  STRUCTURED-DATA — No JSON-LD found

That's 12 actionable findings from a single command. Each one with a clear explanation and fix.

CI integration — catch regressions before they ship

This is where it gets really useful. Add it to your GitHub Actions pipeline:

name: SEO Audit
on:
  push:
    branches: [main]

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: JosephDoUrden/vercel-seo-audit@v1
        with:
          url: https://your-site.com
          strict: true
          report: json

With --strict, any warning fails your build. Merge a PR that accidentally adds noindex to your homepage? CI catches it before it reaches production.

You can also use --diff to compare against a previous audit:

# Save today's report
vercel-seo-audit https://your-site.com --report json

# Next week, compare
vercel-seo-audit https://your-site.com --diff report.json

It'll tell you exactly which issues are new, which were resolved, and which are unchanged.

Config file for teams

Tired of typing the same flags every time? Create a .seoauditrc.json in your project root:

{
  "url": "https://your-site.com",
  "strict": true,
  "userAgent": "googlebot",
  "pages": ["/docs", "/pricing", "/about"],
  "report": "json",
  "timeout": 15000
}

Then just run vercel-seo-audit with no arguments. CLI flags always override the config, so individual devs can still customise their local runs.

How it works under the hood

If you're curious about the architecture, the tool uses a two-phase execution model:

Phase 1 runs robots.txt and redirect checks in parallel. These produce prerequisite data (like the robots.txt content and response headers) that other modules need.

Phase 2 runs everything else in parallel — sitemap, metadata, favicon, Next.js detection, structured data, i18n, images, and security headers. Each module gets an AuditContext with shared data from Phase 1.

Phase 3 (optional, with --crawl) fetches every URL from your sitemap and runs a subset of checks against each page, with configurable concurrency.

Every module uses Promise.allSettled(), so if one check fails (say, a timeout on sitemap.xml), the rest still complete. You always get results, even if your site is partially unreachable.

The whole thing is written in TypeScript, runs on Node.js 18+, and has zero runtime dependencies beyond chalk (colours), cheerio (HTML parsing), commander (CLI), and fast-xml-parser (sitemap parsing). No headless browser. No Puppeteer. Just HTTP requests and HTML analysis, which is why it finishes in 2-3 seconds.

The checks I wish someone had told me about

Let me highlight a few non-obvious checks that have saved me personally:

X-Robots-Tag header. You can have a perfectly clean HTML page with no noindex meta tag, but if your middleware or CDN is adding an X-Robots-Tag: noindex header, Google won't index it. This one is genuinely invisible unless you check response headers manually. The tool catches it automatically.

Sitemap/robots.txt cross-reference. Your sitemap.xml says URLs live at https://example.com/blog/... but your robots.txt Sitemap: directive points to https://www.example.com/sitemap.xml. Subtle, but it confuses crawlers.

hreflang reciprocal links. If page A says "my French version is page B", but page B doesn't say "my English version is page A", Google might ignore both hreflang declarations entirely. The tool checks for this.

Relative og:image URLs. Many social media crawlers don't resolve relative URLs. Your og:image of /images/preview.png might work in a browser but show a broken preview on Twitter. The tool flags this specifically.

Getting started

Install and run:

npx vercel-seo-audit https://your-site.com

Or install globally:

npm i -g vercel-seo-audit
vercel-seo-audit https://your-site.com --verbose

Useful flags to know:

# Audit as Googlebot
vercel-seo-audit https://your-site.com --user-agent googlebot

# Check specific pages for redirect issues
vercel-seo-audit https://your-site.com --pages /docs,/pricing,/about

# Full sitemap crawl (default: 50 pages)
vercel-seo-audit https://your-site.com --crawl

# JSON output for scripting
vercel-seo-audit https://your-site.com --json

The project is open source — github.com/JosephDoUrden/vercel-seo-audit. Contributions are welcome, and there are several issues tagged good first issue if you want to get involved.

If your Next.js site isn't showing up in Google, there's almost certainly a technical reason. Don't spend weeks guessing — run the audit and find out in seconds.

I shipped a fix. The PR got closed. And that’s exactly how open source works sometimes 🙂

Yusufhan Sacak — Sat, 07 Feb 2026 22:56:27 +0000

Recently, I worked on an open-source contribution where I:

Fixed a real production issue
Added unit tests
Handled edge cases
Opened a clean, production-safe PR

…and it still got closed.

Not because the code was wrong.

But because product + growth decisions beat engineering.

That’s open source in real companies.

PR for context:
https://github.com/triggerdotdev/trigger.dev/pull/3014

The problem

The issue looked simple:

A user deletes their last organization
…but they still receive marketing emails.

Root cause:

Their contact remains in Loops (the marketing platform).

From an engineering perspective, the solution felt obvious:

If a user has zero organizations → remove them from Loops.

So I implemented exactly that:

Added deleteContact() to LoopsClient
Wired it into the org deletion flow
Guarded it so it only runs when the last org is deleted
Treated 404 as success (contact already gone)
Added unit tests
Covered edge cases

Clean. Deterministic. Production-safe.

The result?

PR closed 😄

Not due to code quality.

The maintainer explained:

Deleting an organization is not the same as deleting a user.
Marketing should be tied to the user, not the organization.
They don’t yet have a full automated account deletion flow.

And then the most startup sentence ever:

We currently do this manually when users contact us.

🙂

What actually happened

I assumed:

System exit → no more emails.

They’re operating on:

Org deleted ≠ user deleted ≠ lead lost.

This wasn’t an engineering disagreement.

It was a product + growth decision.

Classic SaaS.

Important distinction

This wasn’t a bad PR.

This was a:

Product decision override.

The code was fine.
Tests were there.
Edge cases handled.

But the funnel mattered more.

The real win

Even without a merge, I gained:

Experience navigating a production codebase
External API integration
Testable client abstraction
Edge-case driven design
Maintainer feedback
A glimpse into startup product reality

That’s value.

Takeaway

Open source isn’t just about code.

Sometimes you learn:

How GDPR gets postponed
How growth beats engineering
How a “bug” can be intentional behavior

And that’s part of the journey.

TL;DR

I fixed the bug.
The PR was closed.
It was a product call.

Still 100% worth it.

Most Webhook Signatures Are Broken

Yusufhan Sacak — Mon, 02 Feb 2026 15:55:58 +0000

Here’s a Correct, Production-Grade Way to Do It

Webhooks look simple.

You receive a POST request, parse the JSON, check a signature, and move on.

But in real production systems — especially in finance, billing, or automation — webhook security is one of the most commonly misunderstood and incorrectly implemented parts of backend engineering.

After working with Salesforce, Workato-style integrations, and custom webhook pipelines, I kept seeing the same problems repeated again and again.

So I built a small open-source library to fix them properly.

This article explains what usually goes wrong, what “correct” actually means, and how I implemented it in a generic, Stripe-style way.

The Illusion of Webhook Security

Most webhook implementations claim to be “secure” because they:

Use HMAC
Compare a signature
Share a secret

But when you look closely, many of them:

Parse the body before verification
Skip timestamp validation
Have no replay protection
Use unsafe string comparisons
Accidentally re-serialize JSON

All of these break the security model — sometimes silently.

Mistake #1: Not Signing the Raw Body

HMAC signs bytes, not objects.

This is subtle, but critical.

{ "amount": 4999, "currency": "usd" }

and

{"amount":4999,"currency":"usd"}

represent the same data — but not the same bytes.

If you parse JSON and re-stringify it, you change the byte sequence and the signature no longer matches.

Yet many webhook handlers do exactly this because body-parsing middleware runs before verification.

Correct rule:

Always verify the signature against the exact raw body received over the wire.

Verify first. Parse later.

Mistake #2: No Timestamp Validation

If a webhook has no timestamp, a valid request can be replayed forever.

Anyone who captures it once can resend it days, weeks, or months later — and your system will happily accept it.

This is not theoretical. It happens.

Correct rule:

Every webhook must include a timestamp, validated within a strict tolerance window.

Stripe uses ±5 minutes. That’s a good default.

Mistake #3: No Replay Protection (Even With Timestamps)

Even with timestamps, an attacker can replay a request within the allowed window.

This is especially relevant for:

Payments
State-changing events
Idempotent-looking but non-idempotent logic

Correct rule:

Use a nonce (unique request ID) and reject duplicates.

The verification library should support this, but storage belongs to the consumer (Redis, DB, etc.).

Mistake #4: Unsafe Signature Comparison

Using === or string comparison leaks timing information.

It’s a classic footgun.

Correct rule:

Always use constant-time comparison (crypto.timingSafeEqual).

Anything else is unacceptable in security-sensitive code.

A Stripe-Style Model (Without Stripe Lock-In)

Stripe gets this right. Their model is simple and effective:

HMAC-SHA256
Canonical string
Timestamp
Replay protection
Minimal magic

I wanted the same model, but generic — usable for:

Salesforce-style outbound webhooks
Workato recipes
Internal services
Custom SaaS platforms

That’s why I built webhook-hmac-kit.

webhook-hmac-kit

webhook-hmac-kit is a lightweight, production-ready toolkit for signing and verifying webhook requests.

Design goals:

Correctness over convenience
No framework assumptions
No hidden parsing
No external crypto dependencies

Core features:

HMAC-SHA256 signing
Deterministic canonical string
Timestamp validation
Optional nonce-based replay protection
Constant-time signature comparison
TypeScript-first API
Zero runtime dependencies

Canonical String Format

All signatures are computed over a canonical string:

v1:{timestamp}:{nonce}:{payload}

Example:

v1:1700000000:nonce_abc123:{"event":"payment.completed","amount":4999}

The payload is included verbatim.
No encoding. No normalization. No escaping.

This avoids ambiguity and makes cross-language verification reliable.

Signing a Webhook

import { signWebhook } from 'webhook-hmac-kit';
import crypto from 'node:crypto';

const payload = JSON.stringify({ event: 'payment.completed', amount: 4999 });
const timestamp = Math.floor(Date.now() / 1000);
const nonce = crypto.randomUUID();

const { signature } = signWebhook({
  secret: 'whsec_your_secret',
  payload,
  timestamp,
  nonce,
});

Verifying a Webhook (Correctly)

import { verifyWebhook } from 'webhook-hmac-kit';

await verifyWebhook({
  secret: process.env.WEBHOOK_SECRET!,
  payload: rawBody, // exact bytes received
  signature: headers['x-webhook-signature'],
  timestamp: Number(headers['x-webhook-timestamp']),
  nonce: headers['x-webhook-nonce'],
  nonceValidator: async (nonce) => {
    const exists = await redis.exists(`nonce:${nonce}`);
    if (exists) return false;
    await redis.set(`nonce:${nonce}`, '1', 'EX', 300);
    return true;
  },
});

On failure, the library throws typed errors, so you can respond correctly (401, 400, 409) instead of guessing.

Why Not JWT?

JWTs are great for authentication.

They are not designed for signing arbitrary HTTP payloads.

Webhook signatures need to:

Sign exact raw bytes
Avoid JSON canonicalization issues
Be cheap and fast to verify

HMAC is simpler, safer, and battle-tested for this use case.

Small, Boring, and Correct

This library is intentionally boring.

No decorators.
No magic middleware.
No hidden parsing.

Just the pieces you need to implement webhook security correctly.

Links

If you’ve ever debugged a “signature mismatch” at 2am, you’ll know why this matters.

Why Google Refuses to Index Your Next.js Site

Yusufhan Sacak — Sat, 31 Jan 2026 15:01:12 +0000

You deploy your site.

It loads fast.

Lighthouse looks great.

And yet…

Google refuses to index it.

Search Console throws cryptic messages at you:

Page with redirect
Discovered – currently not indexed
Alternate page with proper canonical

No clear explanation. No clear fix.

If you’re building with Next.js on Vercel, this is far more common than you think.

Let’s break down why this happens — and how to fix it.

The uncomfortable truth

Google doesn’t index websites.

Google indexes URLs.

And modern Next.js apps are very good at accidentally breaking URL consistency.

Most indexing issues aren’t “SEO problems”.

They’re infrastructure and routing problems.

1. Redirects that look harmless (but aren’t)

One of the most common issues:


/about → 308 → /

From a developer’s perspective, this seems fine.

From Google’s perspective, it’s a red flag.

When Google sees:

a URL
that always redirects
to another URL
without a strong reason

…it often decides:

“I won’t index this. It’s a duplicate or soft-canonical.”

Why does this happen in Next.js

Trailing slash mismatches
redirects() in next.config.js
Middleware redirects
App Router defaults using 308 Permanent Redirect

308 is permanent. Google takes it very seriously.

If /about should exist → serve it as 200.

If it shouldn’t → remove internal links pointing to it.

2. “Discovered – currently not indexed” isn’t a crawl problem

This one scares people.

It sounds like Google is still working on it.

In reality, it often means:

“We saw this URL. We decided it’s not worth indexing.”

Common causes:

No sitemap
URL only reachable through redirects
Weak canonical signals
Conflicting metadata

Search Console doesn’t tell you which one.

3. Missing sitemap = Google is guessing

Yes, Google can crawl without a sitemap.

But for modern SPA / SSR hybrids, that’s a gamble.

Without a sitemap:

Google relies on internal links
Redirected pages may never be considered canonical
Crawling frequency drops

In Next.js App Router, the fix is trivial — but often forgotten.

No sitemap → lower trust → slower or no indexing.

4. `robots.txt` isn’t optional anymore

A surprising number of Vercel deployments ship with no robots.txt.

Google then has:

no crawl hints
no sitemap reference
no explicit allow/disallow rules

This doesn’t block indexing —

but it removes a strong trust signal.

In competitive SERPs, that matters.

5. Canonicals you didn’t mean to create

Next.js generates metadata beautifully — until it doesn’t.

Problems I see constantly:

Canonical points to /
Canonical mismatches between HTTP / HTTPS
Canonical missing entirely on subpages

Google follows canonicals more than internal links.

If your canonical is wrong, Google will obey it — even if it kills indexing.

6. Vercel + Next.js = hidden crawler behavior

Vercel is fantastic, but it introduces quirks:

Edge middleware redirects
Platform-level HTTPS enforcement
Automatic handling of www vs non-www

These are invisible in your code — but very visible to crawlers.

If you don’t observe the raw HTTP behavior, you won’t see the issue.

Why Search Console doesn’t help much

Google Search Console reports symptoms, not causes.

It tells you:

something is wrong

It does not tell you:

which redirect
which header
which canonical
which URL pattern triggered it

That gap is where most developers get stuck.

The fix: audit your site like a crawler

You need to think like Googlebot:

What status code do I get?
Do I get redirected?
Is there a canonical?
Is this URL in the sitemap?
Is robots.txt guiding me?

That’s exactly why I built vercel-seo-audit.

npm i vercel-seo-audit
vercel-seo-audit https://yoursite.com

Open source CLI

👉 https://github.com/JosephDoUrden/vercel-seo-audit

It doesn’t guess.
It shows you what Google actually sees — and what to fix.

It doesn’t guess.
It shows you what Google actually sees — and what to fix.

Final thought

If Google isn’t indexing your Next.js site, it’s rarely because of:

keywords
content quality
backlinks (at first)

It’s almost always because:

your URLs are lying to Google.

Fix the signals.
Make your routing boring.
And Google will follow.

If you’re shipping on Vercel and fighting indexing issues, you’re not alone — and you’re not crazy.

You’re just dealing with modern web complexity.

DEV Community: Yusufhan Sacak

Designing an AI-Native Content Publishing Pipeline

The Core Idea

System Components

1. Publishing UI

2. Content API

3. Public Rendering Layer

Automation and External Integrations

MCP Integration

Why MCP Matters

Artefacts Instead of Pages

Safety Considerations

Where This Is Going

Why Google Isn't Indexing Your Next.js Site (And How to Find Out in 3 Seconds)

The silent killers nobody warns you about

Introducing vercel-seo-audit

What it actually checks

Real-world examples

A well-configured site

A site with problems

CI integration — catch regressions before they ship

Config file for teams

How it works under the hood

The checks I wish someone had told me about

Getting started

I shipped a fix. The PR got closed. And that’s exactly how open source works sometimes 🙂

The problem

The result?

What actually happened

Important distinction

The real win

Takeaway

TL;DR

Most Webhook Signatures Are Broken

Here’s a Correct, Production-Grade Way to Do It

The Illusion of Webhook Security

Mistake #1: Not Signing the Raw Body

Mistake #2: No Timestamp Validation

Mistake #3: No Replay Protection (Even With Timestamps)

Mistake #4: Unsafe Signature Comparison

A Stripe-Style Model (Without Stripe Lock-In)

webhook-hmac-kit

Canonical String Format

Signing a Webhook

Verifying a Webhook (Correctly)

Why Not JWT?

Small, Boring, and Correct

Links

Why Google Refuses to Index Your Next.js Site

The uncomfortable truth

1. Redirects that look harmless (but aren’t)

Why does this happen in Next.js

2. “Discovered – currently not indexed” isn’t a crawl problem

3. Missing sitemap = Google is guessing

4. robots.txt isn’t optional anymore

5. Canonicals you didn’t mean to create

6. Vercel + Next.js = hidden crawler behavior

Why Search Console doesn’t help much

The fix: audit your site like a crawler

Final thought

4. `robots.txt` isn’t optional anymore