DEV Community: Cenk KURTOĞLU

I built an API-callable llms.txt generator after Lighthouse added an audit

Cenk KURTOĞLU — Sat, 04 Jul 2026 08:44:45 +0000

Lighthouse made `llms.txt` harder to ignore

In May 2026, Chrome Lighthouse documented an optional llms.txt check in its new Agentic Browsing category.

That does not mean llms.txt is a guaranteed ranking factor. Lighthouse currently marks a missing file as N/A and flags server errors when it tries to retrieve one. The practical signal is narrower: machine-readable site summaries are becoming part of the tooling used to evaluate an agent-friendly web.

The file itself is simple Markdown at the root of a domain:

# Example Product

> One sentence explaining what the product does.

## Pages
- [Documentation](https://example.com/docs): Setup and API guides.
- [Pricing](https://example.com/pricing): Plans and limits.

The companion llms-full.txt can include the full text of the selected pages for RAG and content-ingestion workflows.

The repetitive part was the reason I automated it

Creating one file by hand is easy. Repeating the work across client sites, documentation portals, or scheduled content snapshots is not.

So I built an Apify Actor that:

crawls same-domain pages up to a limit you choose;
prefers a site's sitemap when available;
extracts page titles, descriptions, and main content;
outputs both llms.txt and llms-full.txt;
stores a page-level dataset that can be exported as JSON or CSV;
runs from the Apify UI, API, schedules, or automation workflows.

Try it here: llms.txt Generator on Apify

Example input:

{
  "websiteUrl": "https://example.com",
  "maxPages": 50,
  "includeFullText": true
}

When the run finishes, download the generated files from the run's key-value store and review them before publishing at your domain root.

When this is useful

You manage several client sites and want the same repeatable workflow for each.
You want a clean text snapshot for a RAG pipeline.
You want to regenerate files on a schedule as documentation changes.
You need a page inventory alongside the generated files.

The project is intentionally small and open source. If you try it on a site that exposes an edge case, open an issue or leave a comment with the URL pattern and expected output.

Source: GitHub

Reference: Chrome Lighthouse llms.txt audit documentation

If Stripe is not available in your country, check this before rebuilding your SaaS billing

Cenk KURTOĞLU — Fri, 03 Jul 2026 13:45:14 +0000

If Stripe is not available in your country, the tempting move is to rebuild the entire billing system around the first alternative you find.

That is usually too much work too early.

Before replacing everything, I would check the revenue path as a system:

pricing page
  -> checkout provider
  -> payment confirmation
  -> webhook handler
  -> user / organization mapping
  -> entitlement unlock
  -> failed payment recovery
  -> customer support fallback

The provider matters, but the handoffs matter more.

The common mistake

Founders compare payment providers like this:

Stripe supports my country: yes/no
fees: low/high
subscriptions: yes/no
checkout page: yes/no

That is useful, but incomplete.

The bigger question is:

After someone pays, does the correct account get the correct access every time?

If the answer is not proven, you do not have billing. You have a checkout demo.

What I would audit first

1. Pricing CTA

Can a visitor clearly choose a plan and understand what happens next?

2. Checkout ownership

Are you using a payment gateway, merchant of record, invoice flow, or manual payment path?

Each one changes taxes, refunds, support, customer communication, and account recovery.

3. Webhook idempotency

Can the same payment event arrive twice without double-unlocking, double-emailing, or corrupting access state?

4. User mapping

Does payment map to the right userId, organizationId, or workspace?

This gets messy fast in B2B SaaS.

5. Access unlock

Where is the source of truth for paid access?

Do not scatter this across frontend checks, local storage, and one-off database fields.

6. Failure and recovery

What happens when:

checkout succeeds but the webhook is delayed
the customer closes the tab
the payment provider retries
the email address differs from the app account
the subscription is canceled or refunded

This is where most early billing systems break.

Polar, Lemon Squeezy, Paddle, manual invoice, or Stripe?

The right answer depends on your country, product type, tax burden, buyer expectations, and whether you need subscriptions, one-time payments, licenses, or usage credits.

But the implementation checklist is mostly the same:

one clear pricing path
one checkout provider per offer
one webhook handler strategy
one source of truth for entitlement
one support fallback when automation fails

I am reviewing 5 flows today

If you are building a Next.js SaaS and payment access is the blocker, drop your URL in the comments or email it to cengokurtoglu35@gmail.com with the subject Free mini-audit request. I will reply with 2 concrete issues I would check first.

I also packaged the deeper review as a small USD 49 audit:

https://productized-webdev.vercel.app/audit

Related checklist:

https://dev.to/cekuu35/how-i-wire-polar-mor-payments-in-a-nextjs-saas-without-stripe-1pb0

I will review 5 Next.js SaaS landing/payment flows today

Cenk KURTOĞLU — Fri, 03 Jul 2026 13:37:40 +0000

Most early SaaS launches do not fail because the app has no features.

They fail because the first-revenue path is not clear enough:

the landing page does not explain the outcome
the CTA points to a weak next step
pricing is hidden or confusing
checkout is disconnected from the product promise
webhooks exist, but access unlock is not tested
failed payments and recovery paths are ignored
the deployed app has small broken states that scare buyers away

I am reviewing 5 Next.js SaaS landing/payment flows today.

If you are building with Next.js, Stripe, Polar, Lemon Squeezy, or a SaaS boilerplate, drop your URL in the comments and I will reply with 2 concrete issues I would fix first.

What I will look at

1. Landing page clarity

Can a new visitor understand who the product is for, what pain it removes, and what happens after clicking the CTA?

2. Pricing path

Is there a visible route from interest to payment, or does the user need to guess how to buy?

3. Checkout handoff

Does checkout match the plan, product, and promise on the page?

4. Webhook and access unlock

After payment, does the right user or organization get the right access without manual work?

5. Recovery paths

What happens when payment fails, a webhook retries, an email is missed, or a user comes back later?

If you want the deeper version

I also packaged this into a small paid audit:

https://productized-webdev.vercel.app/audit

It covers landing CTA, pricing, checkout, webhook/access unlock, deployment blockers, and the exact implementation path.

I wrote the payment checklist I use here:

https://dev.to/cekuu35/how-i-wire-polar-mor-payments-in-a-nextjs-saas-without-stripe-1pb0

Drop a URL if you want the free 2-issue version. If you do not want to post publicly, email the URL to cengokurtoglu35@gmail.com with the subject Free mini-audit request.

What 'Production-Ready' Actually Means for a Next.js Template (a Checklist)

Cenk KURTOĞLU — Fri, 03 Jul 2026 13:31:32 +0000

"Production-ready" is the most overused phrase in template marketplaces. After building 20 Next.js templates to a strict bar, here's the checklist I actually use to decide whether something deserves the label.

1. More than one page

A landing page is not a website. A production template has real routes — home, features/services, pricing, a blog index with dynamic posts, and contact. If the "template" is one page.tsx, you're buying a screenshot.

✅ At least 5 routes
✅ Shared layout.tsx with nav + footer
✅ Active-link state so users know where they are

2. No dead buttons

Open the demo and click everything. A "Sign up" button that goes nowhere or a nav link that 404s tells you the rest of the code is just as unfinished. Every interactive element should either do something real or be honestly labeled as a demo.

3. Forms that submit

A contact form needs client-side validation, a visible success/error state, and a backend it actually posts to (a Next.js /api route handler is enough). Bonus points if the template documents how to wire it to a real email provider.

const res = await fetch("/api/contact", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify(values),
});
if (res.ok) setStatus("success");

4. SEO that isn't an afterthought

App Router makes this cheap — there's no excuse to skip it:

generateMetadata per route (title, description, canonical)
Open Graph + Twitter card tags so shared links render a preview
sitemap.ts and robots.ts
Structured data (JSON-LD) for the org/product where it fits

5. It builds clean

The bar is simple and non-negotiable:

tsc --noEmit   # 0 errors
next build     # 0 errors

If a template ships with type errors or build warnings, every change you make is gambling. Strict TypeScript isn't gatekeeping — it's the thing that lets a buyer edit confidently.

6. One-file customization

You should be able to rebrand without reading the component tree. A single data.ts / content.ts config holds the name, colors, nav, copy, and pricing. If you have to grep for hardcoded strings across 40 files, it's not a template — it's homework.

7. Honest demo behavior

This is the one most templates get wrong. If a template shows a checkout, it should say "demo checkout — no real payment." A crypto template should say "not investment advice." Pretending to transact is how you generate refund requests and chargebacks.

The short version

Check	Production-ready?
1 page only	❌
Dead buttons	❌
Forms post to a real route	✅
Per-route SEO metadata	✅
`tsc` + `next build` clean	✅
Rebrand from one file	✅
Honest demo labels	✅

I held all 20 of my templates to this list. You can pressure-test them yourself — they're live (e-commerce, online course, hotel booking) — and the source is on my site.

If you want me to audit your own Next.js launch path, I offer a focused review of landing CTA, payment provider, checkout, webhook/access unlock, and production blockers: https://productized-webdev.vercel.app/audit

Direct template checkout:

20-template bundle: https://cengokurtoglu.gumroad.com/l/vuhstz
AI startup template: https://cengokurtoglu.gumroad.com/l/mmpgds
Modern SaaS template: https://cengokurtoglu.gumroad.com/l/butotw What's on your "production-ready" checklist that I left off?

Ship a Client Website in a Day: The Single-Config Pattern for Next.js

Cenk KURTOĞLU — Fri, 03 Jul 2026 13:30:56 +0000

If you do client work, you know the time sink isn't building the site — it's rebuilding the same site for the fifth client with different colors, copy, and a different logo. The fix isn't "another framework." It's a discipline: drive the whole site from one config object so rebranding is data entry, not engineering.

Here's the pattern I use across 20 production templates.

1. One source of truth

Put everything brand-specific in a single typed file:

// src/lib/data.ts
export const site = {
  name: "Lumen Agency",
  domain: "lumen.studio",
  brand: { primary: "#0ea5e9", accent: "#f59e0b", radius: "1rem" },
  contact: { email: "hello@lumen.studio", phone: "+1 555 0100" },
  nav: [
    { label: "Work", href: "/work" },
    { label: "Services", href: "/services" },
    { label: "About", href: "/about" },
    { label: "Contact", href: "/contact" },
  ],
  services: [
    { title: "Brand Identity", desc: "...", icon: "Sparkles" },
    { title: "Web Design", desc: "...", icon: "Layout" },
  ],
} as const;

Because it's as const, TypeScript gives you autocomplete and catches typos in nav hrefs or missing fields before the build does.

2. Map design tokens to CSS variables

Don't scatter hex codes through 40 components. Feed the brand colors into CSS variables once, and let Tailwind read them:

// in the root layout
<body style={{ "--brand": site.brand.primary, "--accent": site.brand.accent }}>

// tailwind.config — tokens point at the variables
theme: { extend: { colors: { brand: "var(--brand)", accent: "var(--accent)" } } }

Now a rebrand is two hex values, and every button, badge, and link updates.

3. Components consume data, never define it

The anti-pattern is a Hero that hardcodes "Welcome to Acme." The pattern is a Hero that takes site.name and site.tagline. Same for nav, footer, pricing tables, and testimonials. The component owns layout; the config owns content.

export function Hero() {
  return (
    <section>
      <h1>{site.tagline}</h1>
      <p>{site.name} — {site.contact.email}</p>
    </section>
  );
}

4. Keep routing conventional

Next.js App Router already gives you multi-page structure for free — app/services/page.tsx, app/blog/[slug]/page.tsx. Use generateMetadata per route so each page gets its own title and Open Graph tags. Clients notice when sharing a link shows a real preview card.

Why this is the freelancer's unfair advantage

With this pattern, a new client engagement looks like: copy template → edit data.ts → swap logo → next build → deploy to Vercel. A day, not a week. You charge for the outcome, not the hours, and your margin goes up because the second, third, and tenth site cost you almost nothing.

I built 20 templates on exactly this pattern (SaaS, agency, restaurant, real estate, e-commerce, and more). You can see them live — digital agency, real estate, e-commerce — or grab the source on my site.

If you want a second pass before sending traffic to a client site, I also packaged a small audit for landing CTA, checkout/payment path, webhook/access unlock, and deployment blockers: https://productized-webdev.vercel.app/audit

Direct template checkout:

20-template bundle: https://cengokurtoglu.gumroad.com/l/vuhstz
AI startup template: https://cengokurtoglu.gumroad.com/l/mmpgds
Modern SaaS template: https://cengokurtoglu.gumroad.com/l/butotw Do you drive your client sites from config, or do you fork-and-edit each time? Curious what's working for other people doing volume client work.

I Built 20 Production-Ready Next.js + Tailwind Templates — Here's the Architecture

Cenk KURTOĞLU — Fri, 03 Jul 2026 13:30:20 +0000

Most "website templates" you buy online are a single landing page with a hero, three feature cards, and a dead "Contact" button. I wanted the opposite: 20 templates that are actually shippable websites — multiple routes, working navigation, real forms, and zero broken buttons. This post is the architecture I landed on.

The constraint that shaped everything: one config file

The single most important decision was that a buyer should never have to hunt through JSX to rebrand a template. Every template reads from one data source — src/lib/data.ts (or content.ts / siteConfig.ts depending on the template). Change the company name, palette, copy, nav links, and pricing in that one file, and the entire site updates.

// src/lib/data.ts
export const site = {
  name: "Nexus",
  tagline: "Ship faster with the all-in-one platform",
  nav: [
    { label: "Features", href: "/features" },
    { label: "Pricing", href: "/pricing" },
    { label: "Blog", href: "/blog" },
  ],
  brand: { primary: "#6366f1", accent: "#22d3ee" },
} as const;

Components consume site rather than hardcoding strings. This is the difference between a template a non-developer can use and one only the author understands.

Stack: boring on purpose

Next.js 15, App Router — file-system routing, server components by default, generateMetadata for per-route SEO.
Tailwind CSS — utility classes keep the design tokens in one place and make rebrands a search-and-replace, not a refactor.
TypeScript, strict — every template ships with tsc --noEmit returning 0 errors and next build returning 0 errors. That's the bar before it counts as done.

No exotic state libraries, no half-integrated CMS. Boring tech means the buyer can read it on day one.

Multi-page from the start

Each template has at least 5 routes (some have 20+): home, a features/services page, pricing, a blog index with dynamic [slug] posts, and a contact page. The nav and footer live in layout.tsx with an active-link helper so the current page is highlighted — small detail, but it's what separates "a page" from "a site."

// active link in the shared layout
const pathname = usePathname();
const isActive = (href: string) =>
  pathname === href ? "text-brand" : "text-muted hover:text-fg";

Forms that actually do something

Every contact form has client-side validation, a success state, and posts to a real /api/contact route handler. Where a template implies a transaction (an e-commerce checkout, a crypto swap), the demo behavior is honestly labeled — e.g. "demo checkout — no real payment" or "not investment advice." A template that pretends to charge a card is a liability, not a feature.

The honesty test

I almost shipped these as single-page landings. A blunt piece of feedback stopped me: a one-page "template" sold as a website feels a little like a scam. So the rule became: if a buyer drops their content in, they should get a real multi-page site, not a glorified hero section. That reframed the whole project.

See them live

All 20 are deployed as live demos (e.g. modern SaaS, AI startup, digital agency). If you want the source, they're available as single templates or a full bundle on my site.

If you are trying to turn a Next.js site into revenue, I also offer a focused audit of the landing, payment path, webhook/access unlock, and launch blockers: https://productized-webdev.vercel.app/audit

Direct template checkout:

20-template bundle: https://cengokurtoglu.gumroad.com/l/vuhstz
AI startup template: https://cengokurtoglu.gumroad.com/l/mmpgds
Modern SaaS template: https://cengokurtoglu.gumroad.com/l/butotw What would you add to a template before calling it "production-ready"? I'm curious where other people draw the line.

How I Wire Polar MoR Payments In A Next.js SaaS Without Stripe

Cenk KURTOĞLU — Fri, 03 Jul 2026 09:31:42 +0000

How I Wire Polar MoR Payments In A Next.js SaaS Without Stripe

Hook

Stripe is great, but it is not always available or practical for indie SaaS founders outside the US/EU.

The part most founders underestimate is not the checkout button. It is the full revenue path:

product or subscription setup
checkout session
webhook verification
user access unlock
failed payment handling
customer portal
deployment secrets
testing the happy path and failure path

If one part is half-wired, you can get paid and still fail to unlock access correctly.

The Stack

For a small Next.js SaaS, my default stack is:

Next.js App Router
TypeScript
hosted auth or simple session auth depending on scope
Polar as Merchant of Record
webhook route for payment/subscription events
database flag for entitlement/access
Vercel deployment

The goal is not to build a giant billing platform. The goal is to get one paid offer working end to end.

The Minimum Payment Flow

A clean first version needs this:

A product or subscription in the payment provider
A checkout URL or generated checkout session
A user identity attached to checkout metadata
A webhook endpoint that verifies the event
A database update that unlocks access
A protected page that checks entitlement before rendering
A manual test checklist before launch

Most bugs happen around steps 3-5.

The Webhook Checklist

Before I consider a payment flow production-ready, I check:

Is the webhook signature verified?
Is the event idempotent?
Can duplicate webhook delivery cause duplicate access or duplicate records?
Is the user mapped through a stable id, not just an email string?
What happens when payment succeeds but the browser tab closes?
What happens when payment fails?
Can the user regain access from a different device?
Are secrets only stored in environment variables?
Is there a simple admin/debug view for recent payment events?

Why I Like A Fixed Scope

For the first revenue version, fixed scope beats open-ended development.

A good first scope is:

one product or one subscription tier
one checkout path
one protected dashboard or download area
one webhook integration
one deployment
one test checklist

Not included:

complex multi-plan billing
custom accounting
marketplace payouts
advanced admin dashboards
weeks of product feature work

This keeps the project shippable.

Common Founder Mistakes

Building product features before payment works
Treating checkout success page as proof of payment
Not testing webhook retries
Using email as the only source of identity
Forgetting cancellation/downgrade behavior
Not writing down the manual test path
Waiting too long to charge real money

Lightweight Audit Offer

If you are building a Next.js SaaS and payments are still unclear, I offer a small payment integration audit.

You send:

your stack
current payment provider or desired provider
pricing model
repo/screenshots if available
what should unlock after payment

I return:

exact integration path
missing pieces
risk points
suggested fixed-scope implementation
whether Polar/Stripe/LemonSqueezy makes sense for your case

Price: $49 / TRY 1,500.

If you want implementation after that, the audit fee can be credited toward the build.

CTA

If this is relevant, send me your stack and pricing model. I will tell you whether your payment flow needs a quick audit or a full implementation.

I also put the audit route and direct checkout products here:

Audit / review route: https://productized-webdev.vercel.app/audit
20 Next.js templates bundle: https://cengokurtoglu.gumroad.com/l/vuhstz
AI Startup template: https://cengokurtoglu.gumroad.com/l/mmpgds
Modern SaaS template: https://cengokurtoglu.gumroad.com/l/butotw

Next.js 15 App Router SEO done right: generateMetadata, dynamic sitemaps, and the one-file strategy

Cenk KURTOĞLU — Tue, 30 Jun 2026 19:07:53 +0000

SEO in Next.js App Router is genuinely good once you understand the three pieces that work together. The mistake I see in most templates and starter kits is treating them as three separate problems. They aren't — they're one system.

This is a walkthrough of the exact pattern I settled on after applying it across 20 production Next.js 15 templates covering niches from SaaS and real estate to e-commerce and hospitality. All code below is from those templates, not contrived examples.

The three pieces

A single typed content config — all text, URLs, and brand values in one place
generateMetadata — static for most pages, dynamic for data-driven routes
sitemap.ts and robots.ts — auto-generated from the same config

Get these three to read from the same source and SEO maintenance essentially disappears.

Piece 1: the content config

Every template has a src/lib/content.ts (or data.ts) that exports typed constants for everything the site needs to display — and everything the meta layer needs to index it.

// src/lib/content.ts
export const SITE = {
  name: "Nexus",
  tagline: "The platform that scales with you.",
  description:
    "Analytics, automation, and collaboration in one platform. Ship faster, decide smarter, grow without limits.",
  url: process.env.NEXT_PUBLIC_SITE_URL ?? "https://nexus.example.com",
  email: "hello@nexus.example.com",
  twitter: "@nexushq",
} as const;

as const is load-bearing: TypeScript narrows the types to literals, so if you reference SITE.name in a metadata title template, you get a type error the moment you accidentally delete the field. The entire SEO layer catches regressions at build time, not after a deploy.

The key discipline: if a value appears in a heading, it should also appear in the metadata. Both read from the same object. No copy-paste drift.

Piece 2a: static metadata (the layout level)

For the root layout, export metadata directly. The title.template field is the one most people skip — it lets every child page get a consistent "Page name · Nexus" format for free, without each page re-specifying the brand.

// src/app/layout.tsx
import type { Metadata, Viewport } from "next";
import { SITE } from "@/lib/content";

export const metadata: Metadata = {
  metadataBase: new URL(SITE.url),                    // resolves relative OG image paths
  title: {
    default: `${SITE.name} — ${SITE.tagline}`,        // home page
    template: `%s · ${SITE.name}`,                    // every other page
  },
  description: SITE.description,
  alternates: { canonical: "/" },
  openGraph: {
    title: `${SITE.name} — Modern SaaS Platform`,
    description: SITE.description,
    type: "website",
    url: SITE.url,
    siteName: SITE.name,
    locale: "en_US",
  },
  twitter: {
    card: "summary_large_image",
    title: `${SITE.name} — Modern SaaS Platform`,
    description: SITE.description,
    site: SITE.twitter,
  },
  robots: {
    index: true,
    follow: true,
    googleBot: { index: true, follow: true, "max-image-preview": "large" },
  },
};

export const viewport: Viewport = {
  themeColor: "#0a0a0f",
  colorScheme: "dark",
};

Three things worth noting:

metadataBase is required for Open Graph images to resolve. Skip it and Next.js will warn on every build that your OG image URLs are relative.
Viewport is now separate from Metadata in Next.js 15. Putting themeColor inside metadata still works but triggers a deprecation warning. Keep them in separate exports.
robots in metadata generates the <meta name="robots"> tag, not robots.txt. You still want robots.ts for the actual file (covered below).

Piece 2b: dynamic metadata for data-driven routes

Static export const metadata doesn't work when the page content changes per URL — a real estate listing, a blog post, a product page. For those, export generateMetadata instead.

Here's the real-estate listing detail page from one of the templates:

// src/app/ilan/[slug]/page.tsx
import type { Metadata } from "next";
import { listings, formatPrice } from "@/data/listings";

// 1. Pre-render at build time (optional but recommended for static content)
export function generateStaticParams() {
  return listings.map((l) => ({ slug: l.slug }));
}

// 2. Per-page SEO from the data
export async function generateMetadata({
  params,
}: {
  params: Promise<{ slug: string }>;    // <-- Promise in Next.js 15
}): Promise<Metadata> {
  const { slug } = await params;
  const listing = listings.find((l) => l.slug === slug);
  if (!listing) return { title: "Listing not found" };

  return {
    title: `${listing.title} — ${formatPrice(listing)}`,
    description: listing.description.slice(0, 155),
    alternates: { canonical: `/ilan/${listing.slug}` },
    openGraph: {
      title: `${listing.title} — ${formatPrice(listing)}`,
      description: listing.description.slice(0, 155),
      type: "website",
    },
  };
}

The params is now a Promise in Next.js 15 — this catches people who copy patterns from Next.js 13/14. If you destructure params synchronously (the old way), you get a runtime error in production even though it might work locally.

The description slice at 155 characters is intentional: Google truncates around 160. Slice at the data level so the metadata object always has a valid string, not a value that might be 3,000 characters from a rich text field.

Piece 3: `sitemap.ts` and `robots.ts`

Both are just TypeScript files that export functions. Next.js calls them at build time and serves the results as /sitemap.xml and /robots.txt. No plugin needed.

The key: the sitemap reads from the same data array as the pages. Add a listing, add a blog post — the sitemap updates on the next build without any manual maintenance.

// src/app/sitemap.ts
import type { MetadataRoute } from "next";
import { listings } from "@/data/listings";

const siteUrl = "https://estora.com"; // same as SITE.url; centralize if you want

export default function sitemap(): MetadataRoute.Sitemap {
  const staticRoutes: MetadataRoute.Sitemap = [
    { url: siteUrl,                  lastModified: new Date(), changeFrequency: "weekly",  priority: 1   },
    { url: `${siteUrl}/listings`,    lastModified: new Date(), changeFrequency: "daily",   priority: 0.9 },
    { url: `${siteUrl}/about`,       lastModified: new Date(), changeFrequency: "monthly", priority: 0.7 },
    { url: `${siteUrl}/contact`,     lastModified: new Date(), changeFrequency: "monthly", priority: 0.7 },
  ];

  const listingRoutes: MetadataRoute.Sitemap = listings.map((l) => ({
    url: `${siteUrl}/ilan/${l.slug}`,
    lastModified: new Date(l.listedDate),
    changeFrequency: "weekly" as const,   // <-- const assertion required to satisfy the union type
    priority: 0.8,
  }));

  return [...staticRoutes, ...listingRoutes];
}

// src/app/robots.ts
import type { MetadataRoute } from "next";

export default function robots(): MetadataRoute.Robots {
  return {
    rules: { userAgent: "*", allow: "/" },
    sitemap: "https://estora.com/sitemap.xml",
  };
}

The "weekly" as const on the dynamic routes is a small gotcha: changeFrequency is a string union type, and TypeScript will complain if the inferred type is just string. Either use as const on the value or annotate the array with MetadataRoute.Sitemap explicitly (which forces the type down).

Putting it together: what the build output looks like

Run next build and you get:

Route (app)                           Size
├ ○ /                                 5.2 kB
├ ○ /about                            3.1 kB
├ ● /ilan/[slug]                      4.8 kB
│   ├ /ilan/modern-penthouse
│   ├ /ilan/garden-apartment
│   └ ... (12 more pages)
├ ○ /sitemap.xml
└ ○ /robots.txt

Every listing page is pre-rendered with its own title, description, and canonical URL baked in. The sitemap lists all of them. No client-side rendering, no runtime SEO gaps.

The one mistake that costs rankings

Canonical URLs. Most templates either skip them or put a hardcoded string in every page file. Both are wrong.

The right approach: canonical at the layout level defaults to the root path, then each dynamic page overrides it with alternates: { canonical: \/ilan/\${slug}}. Pages that don't override inherit the root canonical, which is fine for static pages. Pages that do override it tell Google exactly which URL is the source of truth.

Without the override on dynamic routes, you can end up with dozens of listing pages all canonicalizing to /, which signals duplicate content to crawlers even though the pages are distinct.

Why this pattern scales

When you apply this to 20 templates across completely different domains, the pattern holds because it's mechanical: one config object, one metadata export per route level, one sitemap function. The content changes; the SEO structure doesn't.

The templates I mentioned earlier cover SaaS, real estate, restaurants, e-commerce, gyms, dental clinics, hotels, law firms, and more. Every one uses this exact three-piece pattern. Live demos are at cenkkurtoglu.com/templates if you want to inspect the rendered markup — check the source on any listing page and you'll see the pattern in action.

The code is also the starting point if you'd rather skip the boilerplate and build the domain-specific logic directly.

Quick reference

What	Where	Key detail
Brand/URL constants	`src/lib/content.ts`	`as const`, single source
Root metadata	`src/app/layout.tsx`	`metadataBase`, `title.template`, separate `viewport`
Dynamic page metadata	`generateMetadata` in `[slug]/page.tsx`	`params` is a `Promise` in Next.js 15
Static pre-rendering	`generateStaticParams`	Pair with `generateMetadata`
Sitemap	`src/app/sitemap.ts`	Reads same data array as pages
Robots	`src/app/robots.ts`	Points to sitemap URL
Canonicals	`alternates.canonical`	Override per dynamic route

23 Production-Ready Next.js 15 + Tailwind Templates (Live Demos You Can Click)

Cenk KURTOĞLU — Sun, 28 Jun 2026 08:39:33 +0000

I spent the last few weeks building a set of 23 Next.js 15 + Tailwind CSS templates — one per common business use-case — and deploying every single one to Vercel so you can click and feel them, not just look at a screenshot.

Here's the full gallery, grouped by what you'd actually use them for. All live, all responsive, all with Framer Motion animations.

SaaS & tech

Services & local business

Food & hospitality

Commerce, content & personal

Three quality tiers

To keep the trade-off between speed and polish explicit, three of them are tier references:

Basic — Clean Studio (lightweight, CSS-only)
Standard — Meridian (Framer Motion mid-tier)
Premium — Nexus Studio (cinematic 3D flagship)

One thing that made these maintainable

Every template reads its brand, colors, and copy from a single config file. Want to rebrand the dental template for a different clinic? You touch one file, not 14 components. That single-source-of-truth pattern is the difference between a template you can ship in an afternoon and one you fight for a week.

// src/lib/config.ts — change once, propagates everywhere
export const config = {
  brand: "Acme Clinic",
  primary: "#0ea5e9",
  // ...nav, hero, services, CTA
}

Grab them

The full source is browsable on GitHub, and if you want the packaged source to build on, the tiers are on Gumroad (use LAUNCH20 for 20% off while it's new).

If you'd rather have one tailored to your brand and delivered done, that's what my Fiverr gig is for.

Happy to answer any Next.js / Tailwind questions in the comments 👇

New Technical Article

Cenk KURTOĞLU — Tue, 23 Jun 2026 10:19:06 +0000

Makale hazÄ±r. Dosya: C:\Users\cnkku\income-infrastructure\ecommerce-cro-ultimate-guide.md

Ne yazdÄ±m â€” "The Ultimate Guide to E-commerce Conversion Rate Optimization" (geliÅŸtirici odaklÄ±, Ä°ngilizce â€” Dev.to/Medium Ä°ngilizce platformlar olduÄŸu iÃ§in):

Dev.to front matter (title/tags/canonical_url) hazÄ±r â€” yapÄ±ÅŸtÄ±r-yayÄ±nla
9 bÃ¶lÃ¼m + iÃ§indekiler (anchor linkli), ~2800 kelime, uzun-form
Kod Ã¶rnekleri (gerÃ§ek, Ã§alÄ±ÅŸÄ±r seviyede):
- Funnel event tracker (sendBeacon + keepalive)
- web-vitals ile saha Ã¶lÃ§Ã¼mÃ¼ (LCP/INP/CLS)
- LCP fix (Next.js Image priority, preload, AVIF/WebP)
- CLS fix (aspect-ratio, font-display)
- INP fix (main-thread yielding, optimistic UI)
- Guest checkout, inline validation, cart recovery
- Typed analytics layer + consent gating
- A/B test matematiÄŸi: deterministik hash bucketing, sample-size hesabÄ±, z-test + normalCdf â€” bu kÄ±sÄ±m Ã§oÄŸu CRO yazÄ±sÄ±nda olmaz, mÃ¼hendise hitap eder
SEO uyumu: anahtar kelime baÅŸlÄ±klarda/H2'lerde, iÃ§indekiler, karÅŸÄ±laÅŸtÄ±rma tablolarÄ±, JSON-LD structured data Ã¶rneÄŸi, audit checklist
Sonda CTA (Dev.to engagement iÃ§in)

YayÄ±n notu (senin elin): Dev.to'ya published: false ile gidiyor (Ã¶nce taslak gÃ¶r, sonra yayÄ±nla). Medium'da ise canonical_url'i Ã¶nce Dev.to'da yayÄ±nlayÄ±p o linki koyman SEO aÃ§Ä±sÄ±ndan doÄŸru olur (duplicate content cezasÄ± yememek iÃ§in tek kanonik kaynak).

Ä°stersen TÃ¼rkÃ§e bir versiyonunu da Ã§Ä±karabilirim ya da kapak gÃ¶rseli iÃ§in Higgsfield ile bir hero gÃ¶rseli Ã¼rettirebilirim.

🚀 Build faster: I build and sell modern, production-ready Next.js templates. Check out my templates at cenkkurtoglu.com to save weeks of development time!

Top 5 Modern Next.js SaaS Templates to Launch Your Startup in 2026

Cenk KURTOĞLU — Tue, 23 Jun 2026 10:18:49 +0000

If you're building a SaaS startup in 2026, starting from scratch is the slowest route to market. The ecosystem has matured, and the boilerplate code required for authentication, payments (Stripe/Polar), database connections, and landing page UI components can take weeks to configure properly.

Instead of reinventing the wheel, successful indie hackers and founders are using production-ready Next.js SaaS templates. In this article, we'll cover why you need a starter kit and what to look for when choosing one.

Why Next.js for Your SaaS?

Next.js remains the undisputed king of React frameworks. With features like Server Components, Turbopack, and edge rendering, it provides the perfect balance of SEO performance and dynamic application capabilities.

What Makes a Great SaaS Template?

A solid starter kit should include:

Authentication: Pre-configured with Supabase, Firebase, or NextAuth.
Payments: Stripe or Polar.sh integration for subscriptions.
Database: Prisma or Drizzle ORM configured with PostgreSQL.
UI Components: Tailwind CSS and Radix/shadcn UI for accessible, beautiful components.
SEO & Blog: Built-in MDX blog for inbound marketing.

Stop Building Boilerplates, Start Shipping

The hardest part of any startup is getting the first 100 paying customers, not writing the authentication logic. By leveraging a high-quality Next.js template, you can skip the boring setup phase and immediately focus on building your core features and marketing your product.

Happy coding and keep shipping!

?? Build faster: I build and sell modern, production-ready Next.js templates. Check out my templates at cenkkurtoglu.com to save weeks of development time!

Update: I now keep the direct checkout links here:

20 Next.js templates bundle: https://cengokurtoglu.gumroad.com/l/vuhstz
AI Startup landing page: https://cengokurtoglu.gumroad.com/l/mmpgds
Modern SaaS landing page: https://cengokurtoglu.gumroad.com/l/butotw
Audit / review route: https://productized-webdev.vercel.app/audit

Untitled

Cenk KURTOĞLU — Tue, 23 Jun 2026 09:01:02 +0000

Makale hazÄ±r. Dosya: C:\Users\cnkku\income-infrastructure\ecommerce-cro-ultimate-guide.md

Ne yazdÄ±m â€” "The Ultimate Guide to E-commerce Conversion Rate Optimization" (geliÅŸtirici odaklÄ±, Ä°ngilizce â€” Dev.to/Medium Ä°ngilizce platformlar olduÄŸu iÃ§in):

Dev.to front matter (title/tags/canonical_url) hazÄ±r â€” yapÄ±ÅŸtÄ±r-yayÄ±nla
9 bÃ¶lÃ¼m + iÃ§indekiler (anchor linkli), ~2800 kelime, uzun-form
Kod Ã¶rnekleri (gerÃ§ek, Ã§alÄ±ÅŸÄ±r seviyede):
- Funnel event tracker (sendBeacon + keepalive)
- web-vitals ile saha Ã¶lÃ§Ã¼mÃ¼ (LCP/INP/CLS)
- LCP fix (Next.js Image priority, preload, AVIF/WebP)
- CLS fix (aspect-ratio, font-display)
- INP fix (main-thread yielding, optimistic UI)
- Guest checkout, inline validation, cart recovery
- Typed analytics layer + consent gating
- A/B test matematiÄŸi: deterministik hash bucketing, sample-size hesabÄ±, z-test + normalCdf â€” bu kÄ±sÄ±m Ã§oÄŸu CRO yazÄ±sÄ±nda olmaz, mÃ¼hendise hitap eder
SEO uyumu: anahtar kelime baÅŸlÄ±klarda/H2'lerde, iÃ§indekiler, karÅŸÄ±laÅŸtÄ±rma tablolarÄ±, JSON-LD structured data Ã¶rneÄŸi, audit checklist
Sonda CTA (Dev.to engagement iÃ§in)

Ä°stersen TÃ¼rkÃ§e bir versiyonunu da Ã§Ä±karabilirim ya da kapak gÃ¶rseli iÃ§in Higgsfield ile bir hero gÃ¶rseli Ã¼rettirebilirim.

DEV Community: Cenk KURTOĞLU

I built an API-callable llms.txt generator after Lighthouse added an audit

Lighthouse made llms.txt harder to ignore

The repetitive part was the reason I automated it

When this is useful

If Stripe is not available in your country, check this before rebuilding your SaaS billing

The common mistake

What I would audit first

1. Pricing CTA

2. Checkout ownership

3. Webhook idempotency

4. User mapping

5. Access unlock

6. Failure and recovery

Polar, Lemon Squeezy, Paddle, manual invoice, or Stripe?

I am reviewing 5 flows today

I will review 5 Next.js SaaS landing/payment flows today

What I will look at

1. Landing page clarity

2. Pricing path

3. Checkout handoff

4. Webhook and access unlock

5. Recovery paths

If you want the deeper version

What 'Production-Ready' Actually Means for a Next.js Template (a Checklist)

1. More than one page

2. No dead buttons

3. Forms that submit

4. SEO that isn't an afterthought

5. It builds clean

6. One-file customization

7. Honest demo behavior

The short version

Ship a Client Website in a Day: The Single-Config Pattern for Next.js

1. One source of truth

2. Map design tokens to CSS variables

3. Components consume data, never define it

4. Keep routing conventional

Why this is the freelancer's unfair advantage

I Built 20 Production-Ready Next.js + Tailwind Templates — Here's the Architecture

The constraint that shaped everything: one config file

Stack: boring on purpose

Multi-page from the start

Forms that actually do something

The honesty test

See them live

How I Wire Polar MoR Payments In A Next.js SaaS Without Stripe

How I Wire Polar MoR Payments In A Next.js SaaS Without Stripe

Hook

The Stack

The Minimum Payment Flow

The Webhook Checklist

Why I Like A Fixed Scope

Common Founder Mistakes

Lightweight Audit Offer

CTA

Next.js 15 App Router SEO done right: generateMetadata, dynamic sitemaps, and the one-file strategy

The three pieces

Piece 1: the content config

Piece 2a: static metadata (the layout level)

Piece 2b: dynamic metadata for data-driven routes

Piece 3: sitemap.ts and robots.ts

Putting it together: what the build output looks like

The one mistake that costs rankings

Why this pattern scales

Quick reference

23 Production-Ready Next.js 15 + Tailwind Templates (Live Demos You Can Click)

SaaS & tech

Services & local business

Food & hospitality

Commerce, content & personal

Three quality tiers

One thing that made these maintainable

Grab them

New Technical Article

Top 5 Modern Next.js SaaS Templates to Launch Your Startup in 2026

Why Next.js for Your SaaS?

What Makes a Great SaaS Template?

Stop Building Boilerplates, Start Shipping

?? Build faster: I build and sell modern, production-ready Next.js templates. Check out my templates at cenkkurtoglu.com to save weeks of development time!

Lighthouse made `llms.txt` harder to ignore

Piece 3: `sitemap.ts` and `robots.ts`