SEO Technical Audit Checklist for Custom Apps

If your custom app “looks fine” in the browser, that’s a weak signal for SEO. One routing change, a header tweak, or a new release can turn a revenue page into something Google can’t fetch, can’t render, or quietly decides not to index.

This technical SEO audit is a pass/fail checklist built for custom-built sites and web apps. It helps you verify the basics that frameworks often break: the right status codes, indexable HTML, correct canonicals, discoverable internal links, and pages that render the same way for Googlebot as they do for users.

The goal is simple: give your dev team (or your consulting partner) clear checks they can run before and after fixes, using tools like Google Search Console, Lighthouse, log files, and crawler tools. You’ll leave with a repeatable workflow for catching crawl, rendering, architecture, and performance issues before they show up as traffic drops.

When Should You Run This Checklist?

A pass/fail checklist only helps SEO when you run it at the moments your codebase can break crawling, rendering, or internal linking. Custom apps change fast, and a single release can flip important pages from indexable to invisible.

  • New launch (or first time you expose the app to search engines): Run the checklist before go-live and again within 48 hours. Launches often ship with default noindex, blocked robots.txt, missing XML sitemaps, or routes that only exist after client-side JavaScript runs.
  • Redesign or navigation refactor: Audit when you change headers, menus, breadcrumbs, or URL patterns. These edits create orphan pages, shallow-to-deep link changes, and accidental canonical mistakes.
  • Migration (domain, subdomain, platform, or hosting): Audit before DNS cutover, immediately after, then weekly for a month. Migrations fail on redirects (302s, chains, loops), mixed HTTP/HTTPS, and lost query parameter handling.
  • Traffic or leads drop: Audit within 24 to 72 hours. Treat sudden changes in Google Search Console clicks, impressions, or indexing as a technical incident until proven otherwise.
  • Framework or rendering changes: Audit after upgrades like Next.js to a new major version, switching SSR to CSR, changing router behavior, or introducing edge rendering. These changes often break link discoverability and cause partial renders in Googlebot.
  • CMS or content pipeline changes: Audit when you change headless CMS logic (Contentful, Sanity, Strapi), template rules, or how you generate titles, canonicals, and structured data.

What “Urgent” Looks Like in a Technical SEO Audit

Escalate immediately if any of these show up: a spike in “Crawled currently not indexed” or “Page with redirect” in Google Search Console, a sitemap that drops large URL counts overnight, core pages returning 4xx/5xx, or Google’s renderer showing missing main content in the URL Inspection “Test Live URL.”

For teams shipping weekly, schedule a lightweight SEO technical audit after any release that touches routing, headers, authentication gates, or caching rules. That is where custom builds quietly break search visibility.

Crawl and Indexation Pass/Fail Checks (Robots, Sitemaps, Canonicals)

Routing, headers, and caching changes often break the basics of SEO: can Googlebot fetch the URL, get a 200 response, see the right canonical, and receive an indexable HTML document. Run these pass-fail checks with Google Search Console, a crawler like Screaming Frog SEO Spider, and a quick command-line test (curl) before you ship fixes.

  • robots.txt: Pass if important paths (/, /products/, /blog/) are allowed and the file returns 200. Fail if you see Disallow: /, blocked query patterns you actually need, or a 403 behind a WAF like Cloudflare. Validate with Google’s robots.txt documentation and testing in Search Console (Google Search Central).
  • XML sitemaps: Pass if Search Console shows “Success,” URLs resolve to 200, and entries match your canonical URLs. Fail if the sitemap lists 3xx, 4xx, 5xx, parameterized URLs, or non-canonical duplicates. Keep sitemaps clean and segmented (for example /sitemap-products.xml, /sitemap-articles.xml).
  • Canonical tags: Pass if each indexable page outputs exactly one rel=canonical pointing to the preferred HTTPS URL. Fail if canonicals point to staging, http, a different host, or the site root for every page (a common templating bug).
  • noindex: Pass if production pages have no noindex meta or X-Robots-Tag. Fail if a “temporary” noindex flag shipped with a feature toggle and stayed on after launch.
  • Redirects: Pass if http to https and non-www to www (or the reverse) uses a single 301 hop. Fail if you chain redirects, mix 302s, or redirect important pages to irrelevant destinations.
  • Status Codes: Pass if real pages return 200, removed pages return 410 or a clean 404, and error pages return 404 (not 200). Fail if you generate “soft 404s” (thin content with 200) or serve 5xx during peak load.

Fast Triage: What to Fix First

Fix blocks and wrong status codes first, then sitemaps and canonicals, then redirect chains. One wrong Disallow or a sitewide noindex can erase indexation faster than any on-page change can recover.

How Do You Audit JavaScript Rendering Without Guessing?

Many custom apps pass crawl and indexation checks and still fail SEO because Googlebot renders a different page than users. Treat JavaScript rendering as a verification workflow: you prove what ships in HTML, what appears only after hydration, and whether internal links exist without executing scripts.

  1. Capture the raw HTML. Fetch a key URL with curl or Chrome DevTools “View page source.” Pass if the main content, title, canonical, and primary internal links exist in the initial HTML. Fail if you see an empty shell like <div id="root"></div> plus script tags.
  2. Compare Google’s render to the user render. In Google Search Console, open URL Inspection, run “Test Live URL,” then view the rendered HTML and screenshot. Pass if the rendered DOM includes the same headings, copy, and links you expect. Fail if key modules never appear or appear without links.
  3. Check link discoverability without clicks. Crawl with Screaming Frog SEO Spider (enable JavaScript rendering for a second crawl). Pass if both crawls find the same core URLs and the same canonical targets. Fail if the non-JS crawl misses product, location, or content pages, or if links exist only behind button handlers.
  4. Spot hydration and route timing bugs. In Chrome DevTools, throttle CPU and network, then hard refresh. Pass if the page shows meaningful HTML immediately and hydration only enhances. Fail if content flashes, disappears, or loads after client-side redirects that change indexable URLs.
  5. Verify SSR and caching headers. For SSR frameworks like Next.js or Nuxt, inspect response headers and HTML for per-route output. Pass if HTML differs by URL and cache rules do not serve the wrong variant. Fail if edge caching or a service worker serves stale HTML across routes.

When Dynamic Rendering Is Warranted

Dynamic rendering (serving bots a pre-rendered HTML snapshot) is a stopgap when you cannot ship SSR quickly and Googlebot consistently misses content or links. Use it only for public, indexable routes, and validate parity with GSC renders. If you can implement SSR, static generation, or pre-rendering (Next.js SSG, Angular Universal), do that instead.

Which Architecture and Internal Linking Issues Hurt Custom Sites Most?

Dynamic rendering can make a page visible to Google, but SEO still stalls when your architecture buries important URLs or strands them without links. Custom apps often rely on client-side state, filters, and infinite scroll, which creates crawl paths humans use but bots cannot follow consistently.

  • Navigation depth: Pass if key commercial pages sit within 3 clicks from the home page (home, category, detail). Fail if important pages require search, modal navigation, or multi-step UI flows that never create crawlable links.
  • Orphan pages: Pass if every indexable URL has at least one internal HTML link from an indexable page. Fail if pages exist only in the XML sitemap, only in an on-site search result, or only behind authenticated entry points.
  • Faceted URLs (filters): Pass if you allow a small, intentional set of filter combinations (for example, “men’s running shoes” plus “brand”) and block or canonicalize the rest. Fail if each filter adds crawlable parameters and creates near-duplicate pages at scale.
  • Pagination and infinite scroll: Pass if you provide crawlable paginated URLs (page 2, page 3) and the first page links to them in HTML. Fail if products load only via infinite scroll with no paginated URLs, or if pagination links render only after JavaScript events.
  • Parameter handling: Pass if tracking parameters (utm_*, gclid) do not create indexable duplicates because canonicals point to the clean URL. Fail if parameters change the canonical, create self-canonicals, or generate indexable “sort” and “view” variants.

Template-Driven Internal Linking Rules Developers Can Ship

Make internal linking predictable by implementing rules in templates and route configs, not in content editor habits. Add breadcrumbs that link to real category URLs. Add “related items” modules that output plain <a href> links in the server-rendered HTML. Build HTML category hubs that link to subcategories and top products, then keep those hubs in the main nav.

Validate architecture with Screaming Frog SEO Spider (crawl depth, orphan detection) and Google Search Console (Internal links report, URL Inspection for rendered links). When JAMD Technologies audits custom builds, these two views usually reveal the same issue: the app has pages, but it does not have crawl paths.

Core Web Vitals Checklist for Custom Builds (LCP, INP, CLS)

Crawl paths mean nothing if users and Google hit a slow, jumpy page. Core Web Vitals are user experience metrics that Google reports at the URL and origin level, and they are a practical part of technical SEO for custom apps because custom rendering, caching, and third-party scripts can quietly tank performance.

  • Data source: Pass if you can see field data in Chrome UX Report (CrUX) and Google Search Console Core Web Vitals. Fail if you only have Lighthouse lab scores and no field signal (common on low-traffic apps). Use PageSpeed Insights to view both lab and CrUX when available.
  • LCP (Largest Contentful Paint): Pass if the LCP element is predictable (hero image, H1 block) and loads early. Fail if LCP is a client-rendered component waiting on API calls. Fixes: pre-render above-the-fold with SSR/SSG (Next.js, Nuxt), preload the hero image, serve AVIF/WebP, and set correct width/height on images.
  • INP (Interaction to Next Paint): Pass if key interactions (menu open, add-to-cart, filter apply) feel immediate on mid-tier mobile. Fail if long tasks block the main thread after hydration. Fixes: code-split routes, defer non-critical JavaScript, remove heavy client analytics, and break up long tasks with requestIdleCallback or scheduling patterns.
  • CLS (Cumulative Layout Shift): Pass if the layout stays stable during load. Fail if banners, cookie dialogs, web fonts, or image placeholders push content down. Fixes: reserve space for ads and banners, use font-display: swap, and avoid inserting DOM above existing content.

Performance Controls Developers Can Ship

  • Caching: Pass if static assets use long-lived Cache-Control with fingerprinted filenames. Fail if every request revalidates or HTML caching serves the wrong route.
  • CDN: Pass if you serve images and static JS/CSS from a CDN like Cloudflare or Fastly. Fail if origin latency dominates TTFB in Lighthouse waterfalls.
  • Third-party scripts: Pass if Tag Manager containers stay lean and scripts load after consent. Fail if chat widgets, heatmaps, and A/B tools block rendering. Audit with Chrome DevTools Coverage and Lighthouse “Reduce JavaScript execution time.”

Run Lighthouse in Chrome DevTools for lab triage, then validate real impact in PageSpeed Insights and Google Search Console Core Web Vitals after shipping fixes.

Post-Fix Validation: What to Recheck in Search Console, Logs, and Crawls

Lighthouse and Core Web Vitals tell you whether the fix improved performance. This loop tells you whether the fix improved SEO outcomes: crawling, rendering, indexation, and tracked conversions. Treat post-fix validation like a release checklist, not a one-time spot check.

  1. Recrawl the site. Run Screaming Frog SEO Spider (or Sitebulb, a technical SEO auditing tool) against the same URL set you used pre-fix. Pass if critical templates return 200, canonicals are stable, internal links are crawlable HTML, and crawl depth for money pages did not increase. Fail if you see new 3xx chains, a spike in “blocked by robots.txt,” or parameter URLs multiplying again.
  2. Re-render key templates. In Google Search Console, use URL Inspection and “Test Live URL” for your homepage, a category, a detail page, and a paginated page. Pass if rendered HTML contains the primary content and internal links you expect. Fail if Google’s screenshot misses modules that users see, or if the rendered HTML drops links that exist in the browser DOM.
  3. Verify indexing signals. Check Search Console for Sitemap status, Page indexing reasons, and canonical selection. Pass if submitted sitemaps process cleanly and Google selects your canonical on representative pages. Fail if “Duplicate, Google chose different canonical” climbs after a canonical or routing change.
  4. Review server logs for Googlebot behavior. Use raw web server logs (Nginx, Apache) or a parser like Screaming Frog Log File Analyser. Pass if Googlebot hits important routes regularly, gets mostly 200s, and does not waste crawl budget on faceted or parameter junk. Fail if you see repeated 5xx for Googlebot, heavy crawling of blocked URLs, or few hits to your real conversion pages.
  5. Validate analytics and conversion tracking. In Google Analytics 4, confirm page_view and your primary conversion events fire once per action after routing changes. Pass if UTM parameters do not create new page paths and conversions still attribute correctly. Fail if SPA navigation stops firing page_view, or if a tag manager change breaks forms and checkout events.

Lightweight Monitoring Cadence

  • Weekly (first month after major fixes): Search Console clicks and impressions, Page indexing reason deltas, sitemap errors.
  • Monthly: One full crawl, one log review sample, one URL Inspection spot check on top templates.
  • Every release that touches routing, headers, auth gates, or caching: rerun this loop on a short URL set.

Assign an owner for each signal (Search Console, logs, crawl, GA4). Then schedule the next validation run before you forget. Technical SEO stays healthy when you treat it like uptime.