Technical SEO for Modern Web Apps: A Code-Level Checklist

However good your content is, search engines will misread your pages, or miss them entirely, if the technical foundation is broken. Technical SEO is largely a developer's job: URLs, rendering, performance and structured data are all decided in code. The list below summarises what I go through before launching a new project.

1. One correct URL: canonical, hreflang and redirects

If the same page opens on http, https, with and without www, search engines see four separate copies. Redirect all of them to a single root with a 301 and give every page an absolute canonical tag.

<link rel="canonical" href="https://example.com/services">
<link rel="alternate" hreflang="en" href="https://example.com/services">
<link rel="alternate" hreflang="tr" href="https://example.com/tr/hizmetler">
<link rel="alternate" hreflang="x-default" href="https://example.com/services">

A common mistake: the base URL comes from an environment variable (for example APP_URL) and the production server keeps the local value (localhost). The site works, so nobody notices, but canonicals, sitemaps and social previews all point to the wrong domain. Check these tags in the page source after every deployment. hreflang must also be reciprocal: if the Turkish page points to the English one, the English page must point back.

2. Rendering: critical content in the first HTML

Google can execute JavaScript, but it does so in a separate rendering queue. If headings, body text and internal links only exist in the browser, indexing can be delayed. So:

• Use server-side rendering (SSR) or static generation (SSG) for content pages; Next.js and Nuxt provide this out of the box, and classic PHP templates already render on the server.
• Navigate with real <a href> links; elements that only redirect via onClick are not crawled.
• Serve a unique <title> and description for every page from the server.

3. Core Web Vitals: measured experience

Google's page experience signals consist of three metrics, assessed at the 75th percentile of real-user data:

• LCP (Largest Contentful Paint): when the largest content element appears; good is 2.5 seconds or less.
• INP (Interaction to Next Paint): responsiveness to interactions; good is 200 ms or less. It replaced FID in March 2024.
• CLS (Cumulative Layout Shift): unexpected layout movement; good is 0.1 or less.

For LCP

Never lazy-load the main above-the-fold image; prioritise it and serve the right size for each device:

<img src="/img/cover-1280.webp"
     srcset="/img/cover-640.webp 640w, /img/cover-1280.webp 1280w"
     sizes="(max-width: 900px) 100vw, 50vw"
     width="1280" height="720" fetchpriority="high" alt="…">

For CLS

Give images and embeds width/height, reserve space for late-loading banners, and preload web fonts.

For INP

Break up long tasks that block the main thread, remove unused JavaScript, and limit third-party scripts (chat widgets, ad tags) to the ones you genuinely need.

4. Crawlability: robots.txt, sitemaps and status codes

• robots.txt should only block areas you don't want crawled (admin panel, internal search results) and reference your sitemap.
• List only canonical URLs that return 200 in the XML sitemap; redirected or noindex pages don't belong there.
• Missing pages must return a real 404; "not found" pages that return 200 (soft 404s) waste crawl budget.
• Avoid redirect chains: an old URL should reach its final destination in one step.

5. Structured data (JSON-LD)

Structured data describes what a page is about in a machine-readable way: person or organisation, article, product, FAQs, breadcrumbs. The rule is simple: everything you mark up must be visible on the page. Validate it with Google's Rich Results Test before going live.

<script type="application/ld+json">
{"@context": "https://schema.org", "@type": "Article",
 "headline": "…", "datePublished": "2026-09-27",
 "author": {"@type": "Person", "name": "…"}}
</script>

6. Server-side performance

A fast front end cannot make up for a slow server. Compress text assets (Brotli or gzip), give static files long cache lifetimes with versioned file names, and cache pages that rarely change on the server. Adding the right database indexes for frequent queries is often the cheapest speed-up of all.

Pre-launch checklist

• http → https and www → one domain, with a single-step 301.
• Canonical and hreflang absolute, on the correct domain and reciprocal.
• Critical content and links present in the first HTML response.
• LCP image prioritised; every image has dimensions and alt text.
• Sitemap lists only canonical 200 URLs; robots.txt points to it.
• JSON-LD matches the visible content and validates.
• Compression, cache headers and security headers enabled.

Technical SEO is never a one-off job; every new feature can break an item on this list. Making these checks part of your release process prevents ranking losses before they happen.