Technical SEO: Speed, Indexing, and Core Web Vitals

You published 40 useful pages. Google indexed 11 of them. The rest sit in a gray zone labeled "Crawled, currently not indexed," and your best buying-intent content never gets a chance to rank.

That gap is almost always technical, not editorial. Great copy that a crawler cannot reach, render, or load quickly behaves like content that does not exist. Technical SEO is the work that makes sure search engines can find your pages, understand them, and serve them fast enough that real buyers stay.

This guide covers the three areas that move the needle for B2B sites: how crawling and indexing actually work, what Core Web Vitals measure and how to pass them, and the speed fixes that matter most. Less theory, more of the checks you can run this week.

Why technical SEO decides whether content ever ranks

Think of it as a pipeline. A page has to be crawled, then indexed, then rendered, then judged on relevance and quality. If it fails at the crawl or index step, none of the later work counts. You can write the best comparison page in your category and lose to a thinner competitor whose site is simply easier for Google to process.

For most B2B sites the technical problems are boring and fixable: duplicate URLs splitting ranking signals, a robots.txt rule blocking a whole section, JavaScript that hides the main content from the crawler, or pages so slow that crawl budget gets wasted. None of these show up in a content audit. All of them cap your results.

Technical work also compounds. Fix your site structure once and every future page inherits clean internal links and faster indexing. That is why it pays to get the foundation right before scaling content. If you are starting fresh, the order of operations in SEO from scratch puts technical health before publishing volume for exactly this reason.

Crawling and indexing: getting your pages found

Crawling is when Googlebot requests your URLs. Indexing is when Google stores and qualifies a page so it can appear in results. A page can be crawled and still not indexed, which is the single most common surprise in Search Console.

Start with the Page Indexing report

Open Google Search Console and go to the Pages report under Indexing. It splits your URLs into indexed and not indexed, with reasons. The reasons are where the diagnosis lives.

A few you will see often:

Crawled, currently not indexed. Google fetched the page and chose not to index it, usually a quality or duplication signal. Thin pages, near-identical templates, and orphaned content land here.
Discovered, currently not indexed. Google knows the URL exists but has not crawled it yet. On large sites this points to crawl budget or internal linking problems.
Duplicate without user-selected canonical. Several URLs look the same and Google picked a different one than you expected.
Excluded by 'noindex' tag. Often an accident left over from staging, and it quietly removes the page from search.

Work the list by volume. One noindex tag on a category template can suppress hundreds of pages at once, so a single fix sometimes recovers a whole section.

Robots.txt, sitemaps, and canonicals

Three files and tags control most of what gets crawled and kept.

Robots.txt tells crawlers where they may not go. The classic own-goal is a Disallow: / left in production after a redesign, which blocks the entire site. Check yours at yourdomain.com/robots.txt and confirm you are not blocking CSS or JavaScript that Google needs to render the page.

XML sitemaps list the URLs you want indexed. Keep them clean: only canonical, indexable, 200-status pages belong there. A sitemap full of redirects and noindex URLs sends mixed signals. Submit it in Search Console and watch the indexed-versus-submitted ratio over time.

Canonical tags tell Google which version of similar pages is the master. Get these wrong and you split ranking signals across duplicates, or worse, canonicalize your money page to a filtered variant nobody searches for. Every page should either be its own canonical or point clearly to the one that is.

A simple indexing checklist

Run this when a page that should rank does not show up:

Is it returning a 200 status (not 404, 301, or 500)?
Does it have a noindex tag? View source and search for "noindex."
Is it blocked in robots.txt?
Does the canonical point to itself, or somewhere else?
Is it in your sitemap?
Does any internal page link to it, or is it orphaned?
Use the URL Inspection tool in Search Console and request indexing if all of the above check out.

Orphaned pages, ones no internal link points to, are an underrated problem. Crawlers follow links, so a page with no inbound links is hard to discover and reads as unimportant. Strong internal linking and site structure solve this and pass authority to the pages you care about.

Core Web Vitals: what they measure and how to pass

Core Web Vitals are three metrics Google uses to score the loading experience of a page. They are part of the ranking system and, more practically, they correlate with bounce and conversion. A slow page loses leads before it loses rankings.

Here are the current metrics and the thresholds Google considers "good." Treat the example field numbers below as illustrative.

Metric	What it measures	Good	Needs work
LCP (Largest Contentful Paint)	Time until the main content loads	≤ 2.5s	> 4.0s
INP (Interaction to Next Paint)	Responsiveness to clicks and taps	≤ 200ms	> 500ms
CLS (Cumulative Layout Shift)	Visual stability as the page loads	≤ 0.1	> 0.25

A note on INP: it replaced First Input Delay as a Core Web Vital in March 2024. If you are working from an older checklist that mentions FID, update it.

LCP: make the main content appear fast

Largest Contentful Paint usually tracks your biggest above-the-fold element, often a hero image or a headline block. Slow LCP comes from slow servers, render-blocking resources, and oversized images.

What moves it:

Serve images in modern formats (WebP or AVIF) and size them to the container. A 4000px hero scaled down in CSS still downloads all 4000 pixels.
Preload the LCP image so the browser fetches it early.
Cut render-blocking CSS and JavaScript in the <head>.
Improve server response time (TTFB) with caching and a CDN.

INP: keep the page responsive

Interaction to Next Paint measures the delay between a user action and the screen updating. Poor INP almost always traces back to heavy JavaScript blocking the main thread while the browser tries to respond.

Reduce third-party scripts, defer non-critical JavaScript, and break up long tasks. B2B sites quietly accumulate tag manager containers, chat widgets, and analytics scripts that each add cost. Audit what loads on every page and remove what does not earn its place.

CLS: stop the layout from jumping

Cumulative Layout Shift punishes content that moves while loading, the kind that makes you tap the wrong button. The usual culprits are images and ads without reserved dimensions, and web fonts that swap and reflow text.

Set explicit width and height attributes on images and video, reserve space for embeds and ad slots, and use font-display: optional or swap carefully so fonts do not push content around.

Field data versus lab data

One trap worth naming. PageSpeed Insights shows two kinds of numbers. Lab data comes from a single simulated test. Field data (the Chrome User Experience Report) reflects what real visitors experienced over the past 28 days. Google ranks on field data. Chase the field numbers, and use lab tests only to diagnose and iterate quickly. The data here can be noisy on low-traffic pages, so judge trends, not single runs.

Site speed beyond Core Web Vitals

Passing the three vitals is a floor, not a finish line. Speed affects crawl efficiency and conversion in ways the metrics do not fully capture, and it shows up directly in pipeline. Slower pages get fewer form fills, so page speed and lead volume move together.

The highest-leverage fixes for most B2B sites:

Images. They are typically the heaviest thing on a page. Compress them, serve next-gen formats, lazy-load anything below the fold, and stop uploading 2MB screenshots straight from a design tool.

Caching and a CDN. A content delivery network serves your assets from a location near each visitor and takes load off your origin server. Browser and server caching mean repeat visits do not refetch everything. For sites with an international B2B audience, a CDN often produces the largest single jump.

Render-blocking resources. Every CSS and JS file in the <head> that the browser must load before painting delays the page. Inline critical CSS, defer the rest, and load third-party scripts asynchronously.

Reduce the request count. Each font, icon set, script, and tracker is a round trip. Audit your tag manager and remove the widgets nobody uses. The fastest resource is the one you never load.

Below is the rough order of how a page reaches a visitor. Each stage you trim shows up in LCP and in their patience.

Mobile, HTTPS, and structured data

A few foundations that round out a technical audit.

Mobile-first indexing. Google indexes the mobile version of your site, so the mobile experience is the one that ranks. If your mobile pages hide content, load slower, or break navigation, that is what Google sees. Test on a real phone, not just a resized browser window.

HTTPS. Secure pages are a baseline ranking signal and a trust signal for buyers. Make sure every page loads over HTTPS, redirect HTTP to HTTPS site-wide, and fix mixed-content warnings where a secure page pulls in an insecure asset.

Structured data. Schema markup helps Google understand your content and can earn rich results (FAQ, breadcrumb, organization, article). It will not rank a weak page, and it pairs naturally with strong on-page SEO such as clean titles and headings. Validate it with the Rich Results Test before shipping.

Common technical SEO mistakes

The patterns that quietly cost B2B sites traffic:

Blocking CSS or JS in robots.txt so Google cannot render the page.
Leaving a noindex tag on production templates after a redesign.
Letting parameter URLs and filters create thousands of duplicate pages with no canonical strategy.
Treating a single lab score in PageSpeed Insights as the truth instead of field data.
Publishing content faster than the site can index it, with no internal links pointing to new pages.
Migrating a site without mapping old URLs to new ones, dropping redirects, and watching rankings evaporate.

That last one deserves its own warning. A botched migration can erase years of SEO equity in a weekend. Map every URL, set 301 redirects, and keep the old sitemap live long enough for Google to recrawl.

FAQ

How often should I run a technical SEO audit?

A full audit once or twice a year for a stable site, plus a quick check after any major change (a redesign, a CMS migration, a new section). Monitor the Search Console Pages report monthly so indexing problems surface early instead of after a traffic drop.

Do Core Web Vitals really affect rankings?

Yes, but they are one signal among many, and relevance still wins. Two pages of equal relevance can be separated by page experience, and a fast page tends to convert better regardless of ranking. Pass the thresholds, then put your energy into content and links.

What is crawl budget and should I worry about it?

Crawl budget is roughly how many of your pages Google will crawl in a given window. Sites under a few thousand URLs rarely need to think about it. Large sites with many parameter URLs, filters, and thin pages can waste budget on junk, leaving important pages uncrawled. Cleaner architecture fixes most of it.

Can I do technical SEO without a developer?

Some of it. You can audit indexing in Search Console, fix sitemaps and robots.txt, compress images, and add schema through many CMS plugins. Deeper work, like reducing render-blocking JavaScript or fixing INP, usually needs developer time. Know which bucket each task falls into before you scope the work.

Why are my pages "Crawled, currently not indexed"?

Google fetched them and decided they were not worth indexing yet, most often a quality or duplication signal. Strengthen thin pages, remove near-duplicates, add internal links from relevant pages, and make sure each page answers a real query better than what already ranks.

Is technical SEO a one-time project?

No. The initial cleanup is a project, but indexing, speed, and Core Web Vitals drift as you add content, plugins, and third-party scripts. Treat it as maintenance with periodic deep checks rather than a box you tick once.

The short version

Technical SEO is the difference between content that ranks and content that never gets seen. Work the foundation in order:

Confirm your important pages are crawled and indexed in Search Console.
Clean up robots.txt, sitemaps, and canonicals so signals are not split or blocked.
Pass Core Web Vitals using field data: LCP under 2.5s, INP under 200ms, CLS under 0.1.
Compress images, add a CDN and caching, and cut render-blocking scripts.
Serve a fast mobile experience over HTTPS, and validate your structured data.

If your traffic has plateaued and the content looks solid, the cap is usually technical, and it is fixable. A focused B2B SEO program starts here, with a healthy site that search engines can read and buyers do not abandon. If you would like a second set of eyes, ask us for a short technical audit of your site: we will tell you what is blocking your pages from ranking and what to fix first.