Technical SEO checklist for product websites

Why does technical SEO matter for product companies?

This article is part of our SEO and content strategy guide. Start there for the big picture.

Google reports that 53% of mobile users leave sites taking longer than three seconds to load (Google/SOASTA Research, 2017). Technical SEO is the foundation that determines whether anyone finds your content at all. Product teams forget this constantly.

Here’s what I see happen. A product company spends six months building a beautiful marketing site. The copywriting is strong. The design is polished. They publish ten articles, wait for traffic, and nothing happens. The robots.txt file they copied from staging is blocking half the site. Their images are 4MB PNGs. They have no sitemap.

Product teams think in features and sprints. Technical SEO doesn’t fit neatly into a Jira board, so it gets deprioritized. But it’s the infrastructure layer everything else depends on. You can write the best article in your industry. If Google can’t crawl it, index it, and serve it fast, that article doesn’t exist.

I’ve watched this pattern repeat across dozens of client projects. The companies that fix their technical SEO first see results from content within months. The ones that skip it wonder why their blog gets twelve visits a week.

This isn’t complicated. It’s just easy to ignore.

What are Core Web Vitals and why should you care?

According to Google’s page experience documentation, pages meeting all three Core Web Vitals thresholds receive a ranking signal boost in search results. These three metrics measure speed, responsiveness, and visual stability. Most product websites fail at least one of them.

LCP: Largest Contentful Paint

LCP measures how long it takes for the largest visible element to render. That’s usually a hero image or a heading block. The target is under 2.5 seconds. Anything over 4 seconds is poor.

The Chrome UX Report data from 2025 shows that only 53% of websites meet the “good” LCP threshold. That means nearly half of all sites are losing rankings because their main content loads too slowly.

The biggest LCP killers: unoptimized images (serving a 3000px JPEG for a 600px container), render-blocking JavaScript that delays the initial paint, and slow server response times. Fix those three things and you’ll fix most LCP problems.

INP: Interaction to Next Paint

INP replaced First Input Delay in March 2024. It measures how quickly your page responds when someone clicks a button, taps a link, or types in a field. The target is under 200 milliseconds.

This metric matters more for product sites than for blogs because product pages tend to have interactive elements. Pricing calculators, feature toggles, demo request forms. If any of those feel sluggish, INP suffers. Heavy JavaScript frameworks are the usual culprit.

CLS: Cumulative Layout Shift

CLS measures how much the page layout moves around while loading. The target is under 0.1. You’ve experienced bad CLS: you’re about to tap a link and an ad loads above it, pushing everything down. You tap the wrong thing. Infuriating.

Common causes include images without explicit width and height attributes, web fonts that swap and change text size, and third-party embeds (chat widgets, analytics banners) that inject themselves after the initial render. Set dimensions on all media elements. Use font-display: swap with appropriate fallback fonts. Load third-party scripts asynchronously.

Why SSGs give you a head start

If you’re running a static site generator like Eleventy, Hugo, or Astro, you’ve already solved several technical SEO problems. Pre-rendered HTML means the browser gets exactly what it needs without waiting for JavaScript to build the page.

This site runs on Eleventy. Our Lighthouse performance scores consistently hit 95+ without any exotic optimization. No hydration. No client-side rendering bottleneck. Plain HTML files served from a CDN.

Compare that to a React SPA where the browser downloads a JavaScript bundle, parses it, executes it, then renders your content. By the time your hero section appears, two or three seconds have passed. A study by Wix Engineering found that every 100ms improvement in LCP correlated with a 0.3% increase in conversion rates.

Not every product company can switch to an SSG overnight. But if you’re building a new marketing site or blog, start with one. You’ll thank yourself later.

How does crawlability work?

A Botify analysis found that Google doesn’t crawl 51% of pages on enterprise websites. If search engines can’t find your pages, nothing else you do matters. Crawlability is step zero.

Robots.txt: the file everyone gets wrong

Your robots.txt file tells search engines which parts of your site they can access. It’s also the file that causes the most self-inflicted SEO damage I’ve ever seen.

The classic mistake: your staging environment has Disallow: / to prevent Google from indexing test content. Someone deploys that robots.txt to production. Suddenly your entire site disappears from search results. I’ve seen this happen to companies with six-figure monthly traffic. It’s always a bad afternoon.

Check your robots.txt right now. Go to yourdomain.com/robots.txt and read it. Make sure it’s not blocking anything you want indexed. If you’re unsure, Google Search Console has a robots.txt tester.

XML sitemaps: your table of contents for Google

An XML sitemap lists every page you want search engines to index. It’s a simple file, but it tells Google exactly what exists on your site and when each page was last updated.

Auto-generate your sitemap. Every major CMS and SSG has a plugin or built-in feature for this. Don’t maintain it by hand. Submit it through Google Search Console and Bing Webmaster Tools. Check it periodically to make sure new pages are appearing.

Keep your sitemap clean. Don’t include pages you’ve set to noindex. Don’t include redirected URLs. A sitemap with 500 URLs that are all valid is better than one with 5,000 URLs where half return errors.

Internal linking: the underrated signal

Orphan pages are invisible pages. If no other page on your site links to a piece of content, search engines may never discover it, even if it’s in your sitemap.

Internal links serve two purposes. They help search engines find and understand the relationship between your pages. And they pass authority from high-performing pages to newer content. That’s why topic cluster models work: the pillar page links to every spoke, and every spoke links back to the pillar.

A reasonable rule: every page should be reachable within three clicks from your homepage. If a user needs five clicks to find your pricing page, Google will treat it as low-priority too. Use tools like Screaming Frog or Ahrefs Site Audit to identify orphan pages and fix them.

Are the right pages getting indexed?

According to Search Engine Journal, Google’s index contains hundreds of billions of pages, but that doesn’t mean all your pages are in it. Getting the right pages indexed (and the wrong ones excluded) is where most product companies make mistakes.

Canonical tags

Canonical tags tell search engines which version of a page is the “official” one. This matters more than most teams realize.

Your content might be accessible at multiple URLs. With a trailing slash and without one. With www and without. With UTM parameters appended. Each of those is technically a different URL, and Google might treat them as separate pages with duplicate content.

Set a self-referencing canonical tag on every page. Pick one URL format (I prefer no www, with trailing slash) and stick with it. Redirect all variations to the canonical version with 301 redirects.

When to use noindex

Not every page should appear in search results. Your thank-you page after form submission? Noindex. Internal search results pages? Noindex. Tag archive pages with thin content? Noindex.

Use the <meta name="robots" content="noindex"> tag on pages that don’t serve a search purpose. This keeps your crawl budget focused on pages that actually deserve rankings.

Duplicate content from URL parameters

E-commerce and SaaS sites are notorious for this. Filtering, sorting, and pagination create hundreds of URL variations for the same content. /products?sort=price and /products?sort=date and /products?page=2 can all look like separate pages to Google.

Handle this with canonical tags pointing to the primary URL, or use Google Search Console’s URL parameters tool to tell Google how to handle each parameter type.

How to check your indexation

Type site:yourdomain.com into Google. That shows you every page Google has indexed. Compare that number to the pages in your sitemap. If there’s a big gap, something is wrong.

Also check Google Search Console’s “Pages” report under “Indexing.” It breaks down exactly which pages are indexed, which are excluded, and why. This is the single most useful report for technical SEO. Check it monthly.

How does structured data help your SEO?

A study by Milestone Research found that pages with schema markup receive up to 40% more organic clicks than pages without it. Structured data tells search engines what your content is, not just what it says.

JSON-LD: the right format

There are three formats for structured data: JSON-LD, Microdata, and RDFa. Use JSON-LD. Google recommends it. It lives in a script tag in your page head, separate from your HTML content. It’s easier to implement, maintain, and debug.

Here’s what a basic Article schema looks like in JSON-LD:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Your article title",
  "author": {
    "@type": "Person",
    "name": "Author Name"
  },
  "datePublished": "2026-03-16",
  "dateModified": "2026-03-16"
}

Which schema types actually matter?

I’ll be honest: most schema types don’t move the needle for product companies. Here are the ones that do.

Organization and WebSite schema on your homepage. These establish your entity in Google’s knowledge graph. Include your logo, social profiles, and contact information.

Article schema on every blog post. Include author, dates, and headline. This helps Google understand your content structure and display rich snippets.

FAQPage schema on pages with Q&A sections. This is one of the few schema types that directly generates rich results in search. When your FAQ questions show up as expandable answers in the SERP, click-through rates jump.

BreadcrumbList schema for site navigation. Helps Google understand your site hierarchy and display breadcrumb trails in search results.

LocalBusiness if you have a physical office. This helps with local search visibility and can trigger the knowledge panel for your business.

Skip Product schema unless you’re an e-commerce company. Skip Review schema unless you have legitimate third-party reviews. Adding schema types that don’t match your actual content can hurt more than help.

Testing your structured data

Use Google’s Rich Results Test to validate your implementation. Paste a URL and it shows you exactly what Google can read from your structured data. Fix any errors or warnings it reports.

Google Search Console also has a dedicated “Enhancements” section for each schema type. If your FAQ schema has issues, you’ll see them there. Check it after deploying changes.

Is your site ready for mobile-first indexing?

Google switched to mobile-first indexing as the default in 2023, meaning the mobile version of your site is what Google crawls and ranks (Google Search Central, 2023). If your mobile experience is broken, your desktop rankings suffer too.

The basics of mobile optimization

This shouldn’t need saying in 2026, but I still see product sites that require horizontal scrolling on phones. Or have touch targets so small you need a stylus. The bar isn’t high.

Set your viewport meta tag: <meta name="viewport" content="width=device-width, initial-scale=1">. Make sure all content is accessible on mobile without horizontal scrolling. Set touch targets to at least 48x48 pixels (Google’s recommendation). Ensure text is readable without zooming at a minimum of 16px for body copy.

Test on real devices

Chrome DevTools mobile simulation is useful but imperfect. It doesn’t replicate actual device performance, network conditions, or touch behavior. Buy a mid-range Android phone and test your site on it. That’s closer to what most of your users experience than your MacBook Pro.

If your site feels fast on a three-year-old Android phone with a 4G connection, it’ll feel fast for everyone. That’s the benchmark.

What about security and HTTPS?

HTTPS has been a Google ranking signal since Google confirmed it in 2014. At this point, there’s no excuse for running an HTTP site. Let’s Encrypt provides free SSL certificates. Most hosting providers handle it automatically.

Mixed content warnings

Switching to HTTPS isn’t enough if your page still loads some resources over HTTP. A single HTTP image or script triggers a mixed content warning and can break the secure connection indicator in browsers.

Audit your site for mixed content after enabling HTTPS. Check that all image sources, script tags, stylesheet links, and font imports use HTTPS URLs. Most content management systems have plugins to find and fix these automatically.

Security headers worth adding

Beyond HTTPS, a few HTTP headers improve both security and search engine trust:

• Content-Security-Policy: Controls which resources the browser can load. Prevents cross-site scripting attacks.
• X-Content-Type-Options: nosniff: Stops browsers from MIME-type sniffing. Small but meaningful security improvement.
• Referrer-Policy: Controls how much referrer information is sent with requests. strict-origin-when-cross-origin is a good default.
• Permissions-Policy: Restricts which browser features your site can use. Disable camera, microphone, and geolocation access if you don’t need them.

These don’t directly affect rankings, but they signal a well-maintained site. And a well-maintained site tends to perform better across every metric that does affect rankings.

The technical SEO checklist

Here’s everything above condensed into a list you can actually work through. I’d recommend tackling these in order.

Speed and Core Web Vitals

• [ ] LCP under 2.5 seconds (test with PageSpeed Insights)
• [ ] INP under 200 milliseconds
• [ ] CLS under 0.1
• [ ] Images compressed and served in WebP or AVIF format
• [ ] All images have explicit width and height attributes
• [ ] No render-blocking JavaScript in the document head
• [ ] Fonts loaded with font-display: swap
• [ ] Third-party scripts loaded asynchronously

Crawlability

• [ ] Robots.txt reviewed and correct (not blocking important content)
• [ ] XML sitemap generated automatically and submitted to Search Console
• [ ] No orphan pages (every page has at least one internal link)
• [ ] Key pages reachable within three clicks from the homepage
• [ ] No broken internal links (check with Screaming Frog or Ahrefs)

Indexation

• [ ] Self-referencing canonical tags on every page
• [ ] One URL format enforced (www vs. non-www, trailing slash vs. no trailing slash)
• [ ] 301 redirects for all URL variations
• [ ] Noindex on pages that shouldn’t rank (thank-you pages, tag archives, internal search)
• [ ] URL parameters handled via canonicals or Search Console settings
• [ ] site:yourdomain.com count matches expected indexed pages

Structured data

• [ ] Organization schema on homepage
• [ ] Article schema on all blog posts and articles
• [ ] FAQPage schema on pages with FAQ sections
• [ ] BreadcrumbList schema for navigation
• [ ] All structured data validated with Rich Results Test
• [ ] No errors in Search Console’s Enhancements reports

Mobile

• [ ] Viewport meta tag set correctly
• [ ] No horizontal scrolling on any page
• [ ] Touch targets at least 48x48 pixels
• [ ] Body text at least 16px
• [ ] Tested on a real mid-range mobile device

Security

• [ ] HTTPS enabled with valid SSL certificate
• [ ] No mixed content warnings
• [ ] Content-Security-Policy header set
• [ ] X-Content-Type-Options header set
• [ ] Referrer-Policy header set

Run through this list quarterly. Technical SEO isn’t a one-time project. Sites change, plugins update, new pages get published. What worked last quarter might be broken now because someone pushed a config change on a Friday afternoon.

The good news: once you’ve set this foundation, maintaining it is straightforward. Most of these checks take minutes. The hard part is doing them in the first place.