DEV Community: ENZORA

Next.js App Router SEO checklist: metadata, sitemap.ts, robots.ts, JSON-LD

ENZORA — Thu, 29 Oct 2026 22:13:55 +0000

Search engines still reward boring technical hygiene. App Router makes the right things easier—central metadata, file-based sitemap and robots—but only if you wire them consistently across routes. This checklist reflects how we keep a multi-page agency site indexable on a single Vercel project (enzora.vercel.app), without buying SEO plugins or duplicate WordPress stacks.

1. One canonical host

Pick one HTTPS origin and use it everywhere: metadataBase, canonical tags, JSON-LD url fields, and sitemap.xml locs. We read NEXT_PUBLIC_SITE_URL with a default of https://enzora.vercel.app so previews can override without forked code.

Helper:

export const siteUrl = (process.env.NEXT_PUBLIC_SITE_URL ?? "https://enzora.vercel.app").replace(/\/$/, "");

Every indexable route should export alternates.canonical as an absolute URL on that host, not a relative path alone. Relative canonicals break when content is scraped from staging.

2. Metadata API per route

Layout defaults

app/layout.tsx sets site-wide title template, description, Open Graph defaults, icons, and Search Console verification. Keep verification dual-path:

HTML file in /public/google*.html (legacy but reliable).
metadata.verification.google fed by NEXT_PUBLIC_GOOGLE_SITE_VERIFICATION for tag-based verification.

Page-level overrides

Each marketing route exports metadata or generateMetadata:

Title ~50–60 characters, primary keyword near the front.
Description ~150–160 characters, honest click-worthy copy (no fake guarantees).
openGraph title/description/url aligned with canonical.
twitter card set to summary_large_image when OG images exist.

Dynamic segments (services/[slug], blog/[slug]) should compute metadata from a single content source—do not hand-edit fifty copies.

3. Exactly one H1, intentional headings

App Router does not police heading order; designers do. Each page gets one H1 matching search intent. Section titles use H2/H3. Avoid duplicating the site name in every H1 unless the page is the home page.

For service hubs, pair the H1 with a short intro paragraph that mentions the primary keyword naturally in the first 100 words, then link internally to related hubs (web design → ecommerce → SEO).

4. `sitemap.ts` that mirrors reality

Use app/sitemap.ts, not a static public/sitemap.xml that rots. Build locs from:

Static marketing paths (home, services index, packages, legal).
All service detail slugs you actually ship (including hub routes like /services/web-design).
Blog posts from your data layer.
Location/market pages if you have them.

Set sensible changeFrequency and priority, but remember Google largely ignores those fields—they are still useful for your own audits.

When you add a hub route, add it to the generator the same day. CI can fetch /sitemap.xml and assert critical URLs exist.

5. `robots.ts` with explicit disallows

app/robots.ts should:

Allow / for normal crawling.
Point to the absolute sitemap URL on your canonical host.
Disallow non-content paths: /api/, /_next/, preview or demo trees you mark noindex (we disallow /work static demos that are intentionally non-indexable).

Do not block CSS or JS—Google needs assets to render pages.

6. Redirects instead of duplicate URLs

When consolidating service slugs (for example /services/online-stores → /services/ecommerce), implement 301 redirects in next.config.ts. Update internal links and the sitemap to the canonical slug only. Keep redirects for at least a year; search engines are slow to forget old URLs.

7. Open Graph images

app/opengraph-image.tsx at the root covers defaults. Dynamic segments can expose opengraph-image.tsx with generateStaticParams for high-value routes (services hubs, blog posts). Keep layouts simple—Satori fails on complex nested flex unless every multi-child div sets display: "flex".

8. JSON-LD with stable `@id`s

Structured data should match visible content:

Organization / ProfessionalService sitewide with legal name, phone, email, postal address, and sameAs social URLs you actually operate—never a similarly named third-party LinkedIn page.
FAQPage generated from the same FAQ array rendered on the page (home FAQ ≠ services FAQ ≠ full FAQ page—each schema matches its visible list).
BlogPosting on articles with datePublished, headline, and publisher linked to the organization @id.
BreadcrumbList on nested pages.

Avoid stuffing schema that is not on the page; rich-result spam invites manual actions.

9. Internal and outbound links

Internal links carry relevance and crawl paths: services ↔ blog ↔ contact. Outbound links to authoritative docs (Google Search Central, web.dev, MDN) signal E-E-A-T when used sparingly and in context—not as a footer link farm.

10. Search Console readiness (human step)

Automated agents cannot click “Submit sitemap” for you. Before launch, verify:

Property for https://enzora.vercel.app (domain or URL prefix).
Ownership via HTML file or meta tag env var.
/sitemap.xml returns 200 with only canonical URLs.
No accidental noindex on money pages.

After deploy, manually submit the sitemap and monitor Coverage for excluded /work or /api paths—those should be intentional.

11. Launch regression checks

Run this on every release candidate:

Fetch /robots.txt and /sitemap.xml on production.
Spot-check five random service pages for canonical + H1 + FAQ schema parity.
Mobile Lighthouse SEO category ≥ 90 (not a ranking factor, but catches missing meta/titles).
Link crawl script against sitemap locs (we use a small Node fetch loop in CI optional).

Closing thought

App Router SEO is mostly routing discipline: one hostname, one slug per intent, metadata generated from the same source as the UI, and sitemap/robots that update when routes do. Fancy content strategies fail when /services/old-name still resolves without a redirect. Fix the plumbing first; the rankings fight happens later, honestly, on the content and product—not on trick metadata.

Originally published on the ENZORA blog. ENZORA builds fast Next.js and Shopify sites, SEO and ads for growing businesses: enzora.vercel.app.

How we got a Next.js App Router site to green Core Web Vitals on Vercel’s free tier

ENZORA — Thu, 29 Oct 2026 22:13:54 +0000

Shipping a marketing site that looks premium is easy. Shipping one that stays fast on mid-range phones, on cold cache, without a performance budget spreadsheet—that takes discipline. We recently tightened ENZORA’s public site on Next.js 15 App Router, hosted on Vercel’s Hobby tier. This article walks through what actually moved Core Web Vitals into the green zone for us, and what we deliberately did not do.

Start with measurement, not guesses

Before changing code, we ran Lighthouse against a production build (next build + next start), not next dev. Dev mode inflates JavaScript cost and hides image optimisation. Mobile emulation matters: most agency traffic lands on phones.

We tracked three field-aligned lab signals:

Largest Contentful Paint (LCP) — usually the hero headline block or a large visual above the fold.
Cumulative Layout Shift (CLS) — often from web fonts, late-loading widgets, or images without reserved space.
Interaction to Next Paint (INP) — main-thread work from hydration, analytics, or heavy client components.

If a metric is red, write down the LCP element name from Lighthouse. That single line saves hours of random bundle trimming.

Keep the critical path boring

Static generation where possible

App Router pages that do not need per-request data should be static. Our home, services, legal, and blog index routes prerender at build time. That gives CDN-friendly HTML and predictable TTFB on Vercel.

Dynamic routes (/blog/[slug], /services/[slug]) use generateStaticParams so builds emit HTML for known URLs. Avoid force-dynamic unless you truly need it.

Fonts without layout drama

We load Inter for body copy with display: "swap" and preload it. A secondary display font loads with preload: false so it does not compete with LCP. Pair swap with consistent fallback metrics in CSS (size-adjust or a close system stack) if CLS spikes when the webfont arrives.

Images: one pipeline

The React tree should use next/image for raster assets so AVIF/WebP negotiation and sizing stay automatic. Enable modern formats in config:

images: { formats: ["image/avif", "image/webp"] },

For decorative portfolio tiles rendered as CSS/SVG mockups, we use explicit aspect-ratio boxes so nothing reflows when lazy sections mount.

Defer non-critical client JavaScript

Marketing sites accumulate “nice to haves”: custom cursors, chat widgets, animation libraries. We moved non-essential UI into a client shell loaded after hydration with next/dynamic and ssr: false. The hero and primary call-to-action render as server components; the floating chat and cursor do not block first paint.

Analytics follows the same rule: Google Analytics 4 loads only after explicit cookie consent. Vercel Analytics and Speed Insights are lightweight first-party scripts and stayed enabled—they report vitals without blocking interaction in our tests.

Third-party scripts are a tax

Every tag manager, chat vendor, or A/B snippet competes with INP. On the free tier you feel this immediately. Our defaults:

No tag manager on launch.
Chat is optional; a lightweight in-house panel replaces a heavy embed until a vendor is required.
Consent-gated GA4 with send_page_view controlled manually on route changes (App Router needs a small client listener).

If marketing insists on a pixel, load it after consent and measure INP again.

CSS and motion without jank

Tailwind v4 kept our stylesheet lean, but motion still caused jank when tied to scroll on the main thread. We gate expensive scroll-driven effects behind a class added on first user interaction (scroll, pointer, keydown). That avoids animating large layers before the user engages—helpful for INP on low-end devices.

Reserve space for fixed cookie banners (position: fixed with a modest height) so accepting cookies does not shove the layout. A small banner beat a full-screen modal for CLS.

Caching and headers

Vercel already sends HSTS and compresses assets. We add long-cache headers for hashed static files in vercel.json and keep HTML on short cache with revalidation. Do not cache HTML aggressively if you ship content fixes often; do cache /logo/*, fonts, and media under /public.

What our numbers looked like

On a production build served locally and spot-checked on the deployed preview, mobile Lighthouse reported LCP around 1.1 s, CLS 0, and INP in the tens of milliseconds after the above passes. Scores move with network noise—treat Lighthouse as a regression guard, not a vanity badge.

Re-run tests after every new script marketing asks for. One embed can undo a week of image optimisation.

Checklist you can copy

Production build + mobile Lighthouse baseline.
Identify the LCP element; optimise that first.
Static-generate marketing routes; static params for slugs.
next/image + AVIF/WebP; fixed aspect ratios for media.
Split client bundles; defer chat, cursor, GA4 until needed/consented.
Gate scroll/motion effects until interaction.
Re-measure after each third-party add.

Green Core Web Vitals on a free tier is not magic—it is scope control. The site still has rich typography and motion; we just refuse to let optional scripts sit on the critical path. If you are tuning a similar agency site, start with consent-gated analytics and dynamic-imported widgets; the vitals usually follow.