Search engines read HTML, not visual layout. This topic covers the foundational HTML that determines whether a page is indexable and understandable at all — titles, meta tags, headings, and links — before any technical SEO tooling.
htmlseometa-tagssearch-engines
Knowledge Check
3 questions · pass at 70%
0/3
easymcq
1. Which of these is a direct search ranking factor, versus one that mainly affects click-through rate on the results page?
Interview Questions
3 questions
Cheatsheet
Download-ready reference
Cheatsheet
Essential <head> tags:
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Unique, descriptive, <60 chars</title>
<meta name="description" content="~155-160 chars, genuine summary">
<link rel="canonical" href="...">
Heading structure: one <h1> per page = the page's topic (not the site brand)
Links:
Descriptive anchor text, never "click here"
Internal links help crawlers discover + understand site structure
Images: alt="describes the image content" (empty alt="" only if purely decorative)
robots.txt (site root, NOT a security mechanism):
User-agent: *
Disallow: /admin/
Sitemap: https://example.com/sitemap.xml
Per-page indexing control:
<meta name="robots" content="noindex, follow"> don't index, but follow links
<meta name="robots" content="noindex, nofollow"> don't index, don't follow links
JS rendering & SEO:
Content only in client-rendered JS → indexed slower (2nd pass) or not at all (non-Google crawlers)
Fix: SSR/SSG for anything that matters for ranking
Rule of thumb: good SEO fundamentals ≈ correct, meaningful, server-rendered HTML.
Search engines crawl HTML (and increasingly execute JavaScript, but with real caveats — see below). Everything an engine knows about a page's topic, importance, and relationship to other pages starts with the raw markup. Good SEO fundamentals are mostly "write correct, meaningful HTML" — the same practices that help accessibility and maintainability also help search ranking, because both are ultimately about making a document's meaning legible to something that isn't a human eyeballing the rendered page.
<head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1" /> <title>Closures in JavaScript — A Deep Dive | Frontend Mastery</title> <meta name="description" content="Learn how JavaScript closures work under the hood, common mistakes, and how they show up in real React bugs." /> <link rel="canonical" href="https://example.com/topic/javascript.closures" /></head>
<title> — the single highest-weight on-page SEO signal, and what's shown as the clickable headline in search results. Should be unique per page, include the primary topic, and stay under ~60 characters before search engines truncate it. Page Title | Site Name is a common, reasonable pattern.
<meta name="description"> — doesn't directly affect ranking, but is frequently shown as the result snippet, so it directly affects click-through rate. Aim for a genuine, specific summary under ~155-160 characters, not keyword stuffing.
<link rel="canonical"> — tells search engines which URL is the "real" one when the same content is reachable at multiple URLs (with/without trailing slash, with tracking query params, paginated duplicates). Prevents duplicate-content dilution of ranking signal.
<meta name="viewport"> — not SEO-labeled, but mobile-friendliness is a ranking factor, and this is required for a page to render correctly on mobile at all.
<h1>Closures in JavaScript</h1><h2>What is a closure?</h2><h3>The lexical environment</h3><h2>Common mistakes</h2>
Search engines use heading structure to understand a page's topic outline — similar to how they'd read a table of contents. This is the same practice covered in Semantic HTML, and it's not a coincidence that accessibility and SEO overlap this heavily: both are about making structure legible to something reading the markup rather than viewing rendered pixels.
Links: the graph search engines actually crawl on#
<!-- Descriptive anchor text, not "click here" --><a href="/topic/closures">Learn about closures</a><!-- Not this --><a href="/topic/closures">click here</a> to learn about closures.
Search engines follow <a href> links to discover new pages — this is literally how crawling works, it's a graph traversal starting from known pages. Anchor text is also a ranking signal for the linked-to page — "click here" tells a crawler nothing about what's on the other end; "Learn about closures" does. Internal linking between related content (see relatedTopics in this very site's topic pages) helps search engines understand site structure and distributes ranking signal between related pages.
<img src="closure-diagram.png" alt="Diagram showing a function's scope chain retaining a reference to its outer variable" />
alt text is read by screen readers (accessibility) and indexed by image search / used as a fallback signal for what the image depicts (SEO) — same attribute, two audiences, one correct practice. An empty alt="" is correct only for purely decorative images that carry no information.
# robots.txt at the site rootUser-agent: *Disallow: /admin/Allow: /Sitemap: https://example.com/sitemap.xml
<!-- Per-page: don't index this page, but do follow its links --><meta name="robots" content="noindex, follow" />
robots.txt is a request, not a security boundary — it tells well-behaved crawlers what not to crawl, but doesn't prevent access and doesn't stop a URL from being indexed if it's linked to from elsewhere (use meta robots noindex or a password/auth wall for that). Common use: excluding admin panels, internal search result pages, or duplicate filtered/sorted product listing variations from being indexed.
Google's crawler executes JavaScript (a headless Chromium-based renderer), but with real caveats: rendering happens in a second pass, sometimes hours to days after the initial crawl (content only in the initial HTML is indexed faster and more reliably), and other search engines (Bing has partial JS support, many others effectively none) don't render JS at all. Practical implication: content critical to a page's core topic and ranking should ideally be present in the server-rendered/initial HTML, not exclusively injected client-side after a JS bundle loads — which is exactly what frameworks like Next.js's Server Components and SSR/SSG solve.
Every indexable page needs a unique, descriptive title. A site where every page has the same <title>Home | MySite</title> (a very common CMS default) gives search engines nothing to distinguish pages by.
2. <h1> used for the site logo/name instead of the page's topic#
<!-- Wrong: every page's <h1> is just the site name --><h1>My Company</h1><p>Article about closures...</p>
The <h1> should describe this specific page's content, not the site brand (that belongs in the header/logo, not necessarily as an <h1>, and definitely not repeated identically on every page as the only <h1>).
# Wrong — a leftover staging-environment robots.txt deployed to productionUser-agent: *Disallow: /
A shockingly common real incident: a Disallow: / meant for a staging environment gets deployed to production and silently deindexes the entire site over the following weeks. Always verify robots.txt after any deploy pipeline change.
5. Content only rendered client-side, with nothing meaningful in the initial HTML#
<!-- Search engines see roughly this on first crawl --><div id="root"></div><script src="/bundle.js"></script>
If the primary content only appears after JS execution and hydration, indexing is slower and less reliable, and non-Google crawlers may never see it at all. Server-render (or statically generate) anything that matters for ranking.
Meta description doesn't directly affect ranking (unlike <title> and content itself) — it affects click-through rate on the search results page. Stuffed, unreadable descriptions get skipped by users and may be replaced by Google with an auto-generated snippet anyway.