SEO Interview Questions and Answers (2026)

SEO interview questions — whether for a marketing or engineering-adjacent role — test whether you understand how search engines actually crawl, render, and rank a page, not just checklist tactics. Here are the ones that come up most.

1. What's the difference between a page being crawlable and being indexable?

   Crawlable means a search engine bot (like Googlebot) can actually discover and fetch the page — it isn't blocked by robots.txt, isn't behind a login/JS-only interaction the crawler can't trigger, and is reachable via a link or sitemap. Indexable means that after crawling, Google is permitted and willing to store the page in its index and potentially rank it — this depends on there being no noindex directive, the page not being a near-duplicate that got canonicalized to another URL, and the content being judged worth indexing. A page can be crawlable but not indexable (e.g., crawled successfully but marked noindex), or blocked from crawling entirely via robots.txt yet still get indexed with just a URL and no snippet if enough external links point to it — which is a common source of confusion.

2. When do you use robots.txt vs a meta noindex tag vs a canonical tag?

   Use robots.txt to prevent crawling of URLs you don't want the bot spending crawl budget on at all — admin panels, internal search results, faceted filter combinations — but note it doesn't guarantee exclusion from the index (a blocked URL can still appear indexed with no description if linked externally). Use <meta name="robots" content="noindex"> when you want the page crawled (so Google sees the noindex directive) but definitely not shown in search results — e.g., a thank-you page or a login-gated preview. Use <link rel="canonical" href="..."> when multiple URLs serve the same or near-duplicate content (e.g., ?sort=price variants of a product listing, or http vs https, or tracking-parameter URLs) and you want to consolidate ranking signals onto one preferred URL rather than blocking anything.

3. What are Core Web Vitals and why do they matter for ranking?

   Core Web Vitals are Google's field metrics for real-world user experience: LCP (Largest Contentful Paint) measures how long the biggest visible content element takes to render — a proxy for perceived load speed, target under 2.5s. INP (Interaction to Next Paint, which replaced FID in 2024) measures the latency between a user interaction (click, tap, key press) and the next visual update, capturing overall responsiveness throughout the page's lifetime, target under 200ms. CLS (Cumulative Layout Shift) measures unexpected layout movement (e.g., an ad loading late and pushing content down), target under 0.1. These are part of Google's "page experience" ranking signal — not the dominant ranking factor (content relevance still matters far more), but they act as a tiebreaker between otherwise similarly relevant pages, and poor Web Vitals correlate strongly with higher bounce rates regardless of SEO impact.

4. Why does structured data (schema.org) help SEO even though it's not a direct ranking factor?

   Structured data — typically JSON-LD embedded in the page — explicitly tells search engines what the content means (this is a Product with this price and rating, this is a Recipe with this cook time, this is an Article by this author on this date) rather than making the engine infer it from unstructured text. Google itself says structured data isn't a direct ranking signal, but it's what unlocks rich results in the SERP — star ratings, price ranges, FAQ dropdowns, breadcrumbs, event dates — which substantially increase click-through rate even at the same ranking position, and higher CTR is something Google's systems do observe and can indirectly reward over time. It also helps disambiguate entities for Google's Knowledge Graph and enables features like voice assistant answers pulling directly from your FAQ schema.

   {"@context":"https://schema.org","@type":"FAQPage","mainEntity":[...]}

5. SSR vs CSR — why does rendering strategy matter for SEO?

   Googlebot does eventually render JavaScript via a headless Chromium instance, but it happens in a second rendering wave after initial crawling, can be delayed by hours to weeks under crawl budget constraints, and other engines (Bing historically, and various AI/LLM crawlers) render JS far less reliably or not at all. With pure client-side rendering (CSR), the initial HTML is often a near-empty <div id="root">, so content only appears after JS executes — risky for SEO-critical pages. Server-side rendering (SSR) or static generation (SSG) sends fully-formed HTML on the first response, so content is immediately visible to any crawler without depending on JS execution succeeding. For SEO-sensitive routes (marketing pages, blog posts, product pages), SSR/SSG or at least hybrid approaches (Next.js, Nuxt, Astro) are strongly preferred over pure client-rendered SPAs; heavily interactive authenticated app sections that don't need indexing can stay CSR.

6. What makes a good sitemap.xml?

   A sitemap.xml should list only canonical, indexable, 200-status URLs you actually want crawled — including a redirected, noindexed, or non-canonical URL just adds noise and can waste crawl budget or confuse signal. Keep it under 50,000 URLs / 50MB per file (use a sitemap index file to reference multiple sitemaps if you exceed that), keep lastmod dates accurate and only update them when content genuinely changes (Google has said it distrusts sitemaps with suspiciously constant or clearly fake lastmod values), and submit it via Google Search Console and reference it in robots.txt. For large sites, splitting sitemaps by content type (e.g., /sitemap-products.xml, /sitemap-blog.xml) makes it easier to spot indexing problems in Search Console per-segment rather than debugging one giant undifferentiated file.

7. What's an effective internal linking strategy?

   Internal links distribute "link equity" (ranking signal) across your site and help crawlers discover and understand the relative importance of pages — pages with more internal links pointing to them, especially from high-authority pages, are treated as more important. Practically: use descriptive, keyword-relevant anchor text rather than "click here"; link from high-traffic/high-authority pages (like your homepage or top blog posts) down to pages you want to boost; build topic clusters where a pillar page links out to detailed subtopic pages that link back to the pillar, reinforcing topical relevance; keep important pages within a few clicks of the homepage rather than buried deep in the architecture; and avoid orphan pages (pages with zero internal links pointing to them) since crawlers rely heavily on links to discover new content, sitemaps alone are a weaker discovery signal.

8. How should you handle duplicate content?

   First, identify the cause — near-identical content commonly arises from URL parameters (session IDs, sort/filter params), printer-friendly page versions, http/https or www/non-www variants, or syndicated content republished elsewhere. The fix depends on cause: use a rel="canonical" tag pointing to the preferred version when both URLs need to stay accessible (e.g., filtered product views); use a 301 redirect when the duplicate should never be accessed directly again (e.g., consolidating www and non-www); use robots.txt or noindex for parameter-driven pages with no unique value (internal search results pages); and for cross-domain syndication, ask the republishing site to include a canonical tag pointing back to your original, or at minimum a link back. Note Google doesn't apply a "duplicate content penalty" per se — it just picks one version to index and ranks that, so unmanaged duplication mainly wastes crawl budget and dilutes ranking signals rather than actively hurting you.

9. What is mobile-first indexing and what does it mean practically?

   Mobile-first indexing means Google predominantly uses the mobile version of your page's content for indexing and ranking, not the desktop version — this has been the default for effectively all sites since 2023-2024. Practically, this means: your mobile page must contain the same content, structured data, and metadata as desktop (a common mistake is stripping content or nav on mobile for a "cleaner" experience, which then hurts SEO because that's the version Google evaluates); images must have proper alt text and lazy-loading that doesn't break crawlability; and mobile page speed matters even more directly since it's the version being evaluated for Core Web Vitals. Using responsive design (same URL, same HTML, CSS-driven layout changes) sidesteps most mobile-first indexing pitfalls entirely, versus maintaining a separate m. subdomain, which requires extra work (bidirectional annotations) to keep signals correctly associated.

10. What page speed factors does a developer actually control, versus things outside their control?

    Developer-controllable factors: image optimization (proper formats like WebP/AVIF, responsive srcset, lazy-loading offscreen images), minimizing render-blocking CSS/JS (deferring non-critical JS, inlining critical CSS), server response time (efficient backend code, caching, a CDN to reduce latency by geography), reducing JavaScript bundle size (code-splitting, tree-shaking, avoiding unnecessary libraries), font-loading strategy (font-display: swap to avoid invisible text), and reserving space for images/ads/embeds to prevent layout shift (explicit width/height attributes). Less controllable: the end user's device performance and network conditions, and third-party scripts you don't own (ad networks, analytics, chat widgets) that you can only choose to load asynchronously, defer, or drop rather than actually speed up. A good mental model: you fully control your own code's efficiency, partially control third-party script impact via loading strategy, and don't control the client's hardware/network at all.

11. What is hreflang and when do you need it?

    hreflang tells search engines which language/regional version of a page to show users based on their locale, for sites with multiple language or country versions of the same content (e.g., en-us, en-gb, fr-fr). It's implemented as <link> tags in the <head> (or HTTP headers, or in the sitemap) on every localized page, listing all other language/region variants including itself (self-referencing), plus an x-default fallback for unmatched locales.

    <link rel="alternate" hreflang="en-us" href="https://example.com/us/" />
    <link rel="alternate" hreflang="fr-fr" href="https://example.com/fr/" />
    <link rel="alternate" hreflang="x-default" href="https://example.com/" />

    The most common mistake is non-reciprocal tags — page A references page B but B doesn't reference A back — which Google will simply ignore. Without hreflang, Google may show the wrong regional version to users, or worse, treat near-identical translated/localized pages as duplicate content.

12. How does Google actually discover new pages on your site?

    Primarily through following links — from other pages on your own site (internal linking), from external sites that link to you, and from your sitemap.xml submitted via Search Console, which acts as a hint/priority list rather than a guarantee of crawling or indexing. Google also discovers URLs via redirects, canonical tags pointing at new pages, and (to a lesser, unofficial extent) from Chrome usage data and other Google-crawled signals. For a brand-new site or page with zero existing backlinks and no internal links pointing to it, the fastest reliable path is submitting the URL directly via Search Console's URL Inspection tool's "Request Indexing," alongside ensuring it's linked from at least one already-indexed page. Purely relying on sitemap submission for a page with no other discovery path can mean a long, unpredictable wait, since sitemaps signal existence but don't guarantee crawl priority.

More prep guides on the AI Interview Bot blog.