Technical SEO basics: the foundation every site needs

What is technical SEO?

Technical SEO is making your website easy for search engines to crawl, understand and trust: site architecture, page speed, mobile usability, HTTPS, structured data and index control. It's distinct from content SEO (what you say) and off-page SEO (who links to you) — it's about removing the obstacles between your content and Google's understanding of it.

Think of it as the plumbing: invisible when it works, catastrophic when it doesn't. A site with brilliant articles but a broken robots.txt, no HTTPS, or 8-second load times is a beautiful shop with the doors welded shut — Google can't get in, or won't stay.

The technical SEO domains, in plain language:

• Crawlability: can Google's bots discover and fetch your pages? (robots.txt, sitemaps, internal linking, no accidental blocks).
• Indexability: of the crawled pages, which should Google keep in its index — and which should stay out (thin pages, duplicates, admin areas)?
• Performance: do pages load fast and stay visually stable? (Core Web Vitals).
• Mobile: does the site work flawlessly on phones? (Google indexes mobile-first.)
• Security: HTTPS everywhere, no mixed content, no hacked pages.
• Understandability: structured data, clean HTML, descriptive titles — helping Google grasp what each page *is*.

What technical SEO is *not*: keyword stuffing, buying links, or any trick. It's the unglamorous infrastructure work that lets legitimate content compete fairly. Sites that skip it don't get penalized so much as quietly ignored — pages that never get indexed can't rank, and nobody tells you.

Where to start on your own site: run the SSL checker for the security layer, the website speed test for performance, and read on for the crawl/index layer — the three checks take ten minutes and reveal most common problems.

How do crawling and indexing actually work?

Google discovers pages by following links (crawling), then decides which to store in its searchable index (indexing), then ranks indexed pages per query. Sites break at each stage: orphan pages never get crawled, noindex tags and robots blocks prevent indexing, and duplicate or thin pages get indexed but never rank.

The pipeline has three stages, and each has its own failure mode:

1. Discovery & crawling. Googlebot follows links — from other sites and from your own internal links — to find pages, then fetches them subject to your robots.txt rules and its crawl budget (how much attention your site gets). Pages with no internal links pointing to them ('orphans') may never be discovered. A logical site structure — homepage → categories → pages, every page reachable within a few clicks — is crawlability in practice.

2. Rendering & indexing. Google renders pages like a browser (executing JavaScript) and decides: index this, or not? Blocks here include robots.txt disallows, noindex meta tags, canonical tags pointing elsewhere, password protection, and accidental staging-site settings ('discourage search engines' left on after launch — tragically common). Check Google Search Console → Pages to see what's indexed versus excluded and *why*.

3. Ranking. Only indexed pages can rank, and ranking weighs content quality, relevance, page experience and authority. Technical SEO's job ends at making sure deserving pages reach this stage healthy — content and links take it from there.

Diagnose with Search Console: the Pages report shows excluded pages with reasons ('Crawled - currently not indexed' often means thin content; 'Discovered - currently not indexed' often means crawl budget/authority limits). Fix the cause, not the symptom — and generate a clean robots.txt with the robots.txt generator rather than hand-writing directives that accidentally block everything.

Why does site speed matter for SEO?

Speed matters for SEO twice: directly, through Core Web Vitals (LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1) as ranking signals, and indirectly, because slow pages increase bounce rates and reduce crawl budget — Googlebot spends its limited crawl allocation faster on slow sites. A fast site gets crawled more, ranked better and converts higher: one fix, three wins.

Google's Core Web Vitals thresholds are public and stable: LCP (main content visible) ≤ 2.5 seconds, INP (interaction responsiveness) ≤ 200ms, CLS (layout stability) ≤ 0.1. These are measured on real users (field data), not lab tests — optimize what visitors experience.

The indirect effects are bigger than the direct ranking signal: slow pages get fewer pages-per-visit, higher bounce rates and lower conversions — user behavior signals Google absolutely notices. And crawl budget: Googlebot allocates limited fetching per site; on a slow site it crawls fewer pages per visit, so new content gets discovered later and deep pages get revisited rarely.

The technical speed program, in priority order: quality hosting (TTFB is the foundation), caching, image optimization (usually 50–80% of page weight — compress with the image compressor), font discipline (fewer weights, display=swap), and JavaScript hygiene (defer non-critical, remove unused). WordPress specifics are in the speed optimization guide; the Core Web Vitals guide explains each metric deeply.

Measure correctly: PageSpeed Insights for Google's view (lab + field), Search Console's Core Web Vitals report for site-wide status, and test the templates that matter (homepage, article, product, checkout) — one fast homepage doesn't certify the site.

What does mobile-first indexing mean for your site?

Google predominantly uses your site's mobile version for indexing and ranking — so the mobile experience *is* the SEO experience. If content, structured data or internal links exist only on desktop, Google may never see them. Test everything on a real mid-range phone: if it's broken, hidden or unusably slow on mobile, it's an SEO problem.

Mobile-first indexing flipped the old assumption: Googlebot now crawls with a mobile user-agent and judges the mobile page. Consequences that still catch sites out:

• Hidden mobile content: content behind tabs/accordions on mobile still counts (Google renders it), but content *removed* on mobile to 'simplify' is invisible to Google. Parity matters.
• Mobile-only breakage: layouts that collapse, menus that don't open, tap targets too small, text too tiny — all user-experience failures Google measures.
• Separate mobile URLs (m.example.com): largely legacy now; if you still run one, the annotation and parity requirements are strict. Responsive design avoids the entire class of problems.
• Speed gap: mobile connections and CPUs are slower — a page that's 'fine' on desktop broadband can be 6 seconds on a Pakistani 4G connection. Test on throttled mobile, not your fiber.

The practical test: borrow a mid-range Android phone, turn off Wi-Fi, and use your site like a customer for ten minutes — navigate, search, fill a form, check out. Every frustration you feel is a ranking and conversion problem wearing a disguise. Fix what you find before any advanced SEO work; mobile usability is foundational.

Also verify the mobile basics technically: viewport meta tag present, no Flash or unplayable content, font sizes readable without zooming, and no intrusive interstitials covering content (Google explicitly demotes these). Search Console's mobile usability reports flag the mechanical issues; the phone-in-hand test finds the human ones.

How do HTTPS and structured data fit in?

HTTPS is a baseline requirement — browsers warn on non-HTTPS pages and Google uses it as a (light) ranking signal; mixed content (HTTPS page loading HTTP resources) breaks the padlock and trust. Structured data (schema markup) doesn't directly boost rankings but earns rich results — star ratings, FAQs, breadcrumbs in search listings — which lift click-through rates significantly.

HTTPS: non-negotiable in 2026. Browsers label HTTP pages 'Not Secure', visitors bounce, and Google confirmed HTTPS as a ranking signal years ago. Implementation checklist: valid certificate covering www and non-www (the SSL checker verifies the chain), all internal links and resources on HTTPS, 301 redirects from HTTP to HTTPS, HSTS header for strict enforcement, and Search Console properties for the HTTPS version. Then hunt mixed content — one http:// image breaks the padlock.

Structured data: schema.org markup (JSON-LD) that tells Google *what* your content is — Article, Product (price, availability, reviews), FAQPage, BreadcrumbList, LocalBusiness, Event. It doesn't directly raise rankings, but it qualifies pages for rich results: review stars, FAQ dropdowns, product info, event dates right in the search listing. Rich results dominate visual space and measurably lift click-through — same ranking, more traffic.

Implement honestly: mark up what's actually on the page (fake review stars are a spam violation that earns manual penalties), validate with Google's Rich Results Test, and prioritize the types matching your content — Product + Review for stores, Article for publishers, FAQPage where you genuinely answer questions, LocalBusiness for physical locations.

Every page on this site carries JSON-LD (BlogPosting, FAQPage, BreadcrumbList) — view-source any article to see the pattern. It's the same honest markup described here: describing real content, not gaming anything.

What is the technical SEO priority fix list?

Fix in this order: (1) unblock crawling/indexing disasters (robots.txt, noindex, Search Console exclusions), (2) HTTPS everywhere with no mixed content, (3) Core Web Vitals into 'good' territory, (4) mobile usability, (5) structured data for rich results, (6) ongoing hygiene (broken links, redirects, sitemaps). Steps 1–2 are emergencies; the rest compound.

Prioritized by impact-per-effort:

• P0 — Indexing emergencies. 'Discourage search engines' left on, robots.txt blocking everything, noindex on live pages, hacked pages indexed. Check Search Console Pages report today — these are silent traffic killers.
• P1 — HTTPS. Certificate valid, all-HTTPS resources, HTTP→HTTPS redirects, HSTS. Baseline trust.
• P2 — Core Web Vitals. LCP/INP/CLS to 'good' on key templates. Biggest ranking-adjacent win after emergencies.
• P3 — Mobile usability. Real-device test + Search Console mobile report. Non-negotiable under mobile-first indexing.
• P4 — Structured data. Eligible rich results implemented honestly and validated.
• P5 — Hygiene (ongoing). Fix broken internal links, chain/clean redirects (one hop, not five), keep XML sitemaps accurate and submitted, prune thin/duplicate pages, maintain logical internal linking to important pages.

Re-audit quarterly: Search Console (coverage, vitals, mobile, security), a crawl with Screaming Frog's free tier (500 URLs) for broken links and redirect chains, and the SSL/speed spot-checks above. Technical SEO decays — plugins update, content sprawls, certificates expire. The sites that stay healthy treat it as maintenance, not a project.

When the list exceeds your time or expertise — deep crawl issues, JavaScript rendering problems, site migrations — professional technical SEO cleanup handles the audit-to-fix cycle end to end, and the on-page checklist covers the content layer that sits on top of this foundation.

Frequently asked questions