Modern SEO and Performance Guide

The fundamentals have not moved much. Crawl, index, render, rank. The targets have raised: Google's render budget is tighter, Bing's IndexNow protocol is now table stakes (Bing pings on publish, every published article), and security headers are increasingly weighted as a quality signal alongside HTTPS itself.

The single most common technical failure we audit is JavaScript-rendered primary content. Frameworks default to server-side rendering for a reason. If a page's main content only resolves after a client-side fetch, Googlebot may render it (eventually, on a delay) but other crawlers (Bingbot, AI bots, Facebook's link preview) often will not. Server-render the main content always. Use client-side hydration for interactivity, not for the words.

FPWS ships every site with a typed schema module, a sitemap generated at build time from the routing tree (with lastmod from git history), IndexNow pinging on every article publish, and security headers configured in next.config.js. None of this is exotic. All of it is too rarely done.

The pattern we ship: a single schema.ts module that exports buildOrganization(), buildPerson(), buildArticle(), buildLocalBusiness(), buildService(), buildBreadcrumb(), buildFAQ(), and so on. Each builder returns a typed object (using schema-dts types). Each entity has a stable @id like https://domain.com/#organization. Pages compose schemas by calling the builders and dropping the result into a single JSON-LD script tag.

The benefits: types catch typos at compile time, refactors update every page that references the entity, the schema graph stays internally consistent, and post-deploy validation finds drift fast. The cost: an afternoon of upfront work per project. Pays for itself within a sprint.

Schema types worth shipping by default: Organization, WebSite (with potentialAction SearchAction), Person (founder), BreadcrumbList (every page), Article (every long-form piece), FAQPage (where Q&A appears), Service (each service page), and the relevant LocalBusiness subtype if applicable. Resist adding schema for the sake of it. Recipe schema on a service page is noise.

INP is the metric that bites most teams. It measures the worst interaction delay on the page (input to next paint), and most React apps have at least one slow interaction lurking, a search filter, a modal open, a tab switch, that pushes INP past 200ms. The fix is usually breaking up long tasks with scheduler.yield(), deferring non-critical work, and pruning the JavaScript bundle.

LCP is mostly an asset problem in 2026. Use Next/Image with explicit width and height, AVIF first then WebP, responsive sizes attribute, and a blur placeholder for the hero image only. Self-host fonts, subset to the characters the page actually uses, preload only above-fold weights, and font-display: swap. Hero LCP under 1.8s on 4G mid-tier mobile is achievable with discipline, not heroics.

CLS is the easiest to fix and the most often missed. Reserve space for every image, ad, and embed. Avoid injecting content above existing content after page load. Use CSS aspect-ratio for media containers. Most CLS regressions we audit come from late-injected cookie banners or chat widgets pushing content down.

The measurement that matters is RUM, not Lighthouse. Lighthouse is useful for catching obvious regressions in CI; Vercel Analytics or Search Console's Core Web Vitals report tells you what real users on real devices actually experience. The two often disagree by 30 percent or more. Trust RUM.

The App Router patterns that materially help SEO: generateMetadata in every page.tsx for typed per-page metadata (title, description, canonical via alternates.canonical, openGraph, twitter), a single root metadata.ts for site-wide defaults that pages can extend, and the dynamic sitemap.ts API for sitemaps generated at build time from the route tree.

Cache Components in Next.js 16 (the use cache directive, cacheLife, cacheTag) let you ship pages that are statically rendered for crawlers but revalidate cleanly when content changes. Pair it with updateTag on the API route or server action that mutates the underlying data. The result: SEO-friendly static rendering with no stale-content lag.

Avoid putting primary content inside client components. 'use client' has its place (form interactions, motion, anything stateful), but the words on the page should render server-side. The pattern we ship: server component owns the layout and content; client components are leaf nodes for interactivity only.

On dynamic routes, use generateStaticParams to pre-render the known set at build time, and let the rest fall through to dynamic rendering with caching. Do not let crawlers hit a slow database query on every request.

The hub-and-spoke pattern is the workhorse: a pillar page covers a topic broadly (3,000 to 4,000 words), and 6 to 12 supporting articles each go deep on a sub-topic and link back to the pillar with descriptive anchor text. The pillar links out to each supporting article. The pattern routes authority efficiently, signals topical depth to search engines, and gives AI engines a clean entity-and-topic graph to attach citations to.

Anchor text matters more than most teams think. Generic 'learn more' or 'read more' anchors give crawlers nothing. Descriptive anchors that name the destination concept ("see our guide on Core Web Vitals in 2026") pass topical signals along the link. Aim for descriptive, varied (not exact-match-keyword on every link, which looks manipulative), and contextually placed inside paragraphs rather than as standalone link lists.

Orphan pages (pages with no internal links pointing to them) are the most common internal-linking failure. They get crawled rarely, ranked weakly, and cited never. Run a monthly audit: for every indexed page, count internal links pointing to it. Anything below three deserves either more links or removal.

The era of "write 3,000 words on every topic so Google ranks you" is over. Google now penalizes thin or padded content explicitly (Helpful Content Update, March 2024 spam update, December 2025 quality refinement that extended E-E-A-T weighting to all competitive query types). AI engines reward concision in the citable passage and depth in the surrounding context. The right answer is to write as long as the topic earns and to engineer the structure for both targets.

The pattern we ship for every long-form piece: TL;DR (60 to 80 words, citable, answers the headline query), 5 to 9 H2 sections each with its own citable answer block plus 2 to 4 paragraphs of body, supporting bullet lists where they aid scannability, an FAQ section of 5 to 8 real questions, and a related-content block linking to the pillar and 2 to 3 sibling articles.

Author bylines are quietly important. Articles signed by a named human, with a Person schema linking to LinkedIn and a real bio, get cited more reliably than unsigned content. AI engines and classical search both weight author entity signals more than they did two years ago. Use one named author per article. Link consistently.

The pattern that works: before writing a line of code on the new site, audit the existing site's full URL inventory (Search Console, sitemap, server logs, crawler tools). Score each URL by traffic and rankings. Decide for each: keep at the same path, move to a new path with a 301, or remove and 410. Build the redirect map as a CSV in the repo, kept under version control, deployed as a redirect config in next.config.js or middleware.

Before launch: stage the new site at a preview URL, validate every key page renders correctly, schema is preserved, metadata matches, internal links resolve. Crawl the staging site with Screaming Frog or equivalent. Fix anything that comes up.

At launch: lower DNS TTLs 24 to 48 hours in advance, deploy at a low-traffic time, monitor server logs for crawler hits, watch Search Console for any indexation drops in the first 72 hours. Submit a sitemap to GSC and BWT immediately. File a change-of-address request in Search Console if the domain itself changed.

For 90 days post-launch: weekly crawl audits, weekly Search Console review for indexation and performance, monthly ranking comparison against pre-launch baseline. Most ranking issues from a replatform surface within 2 to 6 weeks of launch. Catch them early, fix them fast, and the migration ends up neutral or positive.

Search Console is the source of truth for query data and indexation. Bing Webmaster Tools is the source of truth for Bing and Copilot. Anyone who tells you to skip BWT because "Bing doesn't matter" is wrong: Bing's index powers ChatGPT search, DuckDuckGo, and a chunk of Apple Intelligence's web layer. It matters.

DataForSEO covers the layers Google does not give you directly: live SERP data for arbitrary queries, backlink profile changes, competitor rank tracking at scale, and AI-citation monitoring for ChatGPT, Perplexity, and Google AI Overviews. We pull DataForSEO into a monthly dashboard alongside Search Console exports.

The metric that matters most for revenue is conversion attribution, not traffic. Use UTM parameters consistently, fire conversion events in Vercel Analytics (or GA4) with clean source attribution, and tie back to CRM data for lead quality scoring. The goal is not 100,000 monthly visits. The goal is the right 5,000 monthly visits, converting at the rates the business needs.