Search Engine Optimization Interview Questions

Note: SEO interviews reward people who can connect work to revenue rather than to rankings. Traffic that does not convert is a vanity metric.

Cover:

• The site and starting position. Type of site, size, and where it stood — organic sessions, rankings, and revenue at the start.
• The diagnosis. What was actually holding it back: technical issues preventing indexing, thin or duplicated content, no internal linking structure, a weak backlink profile, or targeting the wrong queries entirely.
• What you did, prioritised. Not a list of everything — the two or three things that mattered most and why you chose them first.
• The results, with a timeframe. Organic traffic, rankings for specific target terms, conversions or revenue from organic, and how long it took. SEO results take months, and saying so demonstrates realistic expectations.

If a change did not work, or a core update hurt you, that is a valuable story — everyone in SEO has one.

This is one of the most important skills in SEO, because unrealistic expectations end more engagements than poor work does.

• Be explicit that SEO is a compounding investment, not a campaign. Meaningful movement typically takes three to six months, and competitive terms can take a year. Saying this up front is far better than explaining it in month three.
• Explain what drives the timeline — crawling and indexing delays, the time for content to accumulate authority, and competitors who are also working.
• Set leading indicators, not just lagging ones. Rankings and traffic lag; indexation, crawl stats, pages published, technical issues resolved, and impressions in Search Console move earlier and show progress honestly.
• Never promise a specific ranking. Nobody controls Google's algorithm, and guaranteeing position one is a warning sign of a bad practitioner.
• Flag the risk of core updates, so a fluctuation is understood as normal rather than as failure.

Note: Identifying quick wins to show early progress — fixing indexation problems, updating pages already ranking on page two, or improving title tags on high-impression pages — buys the credibility needed for the slower structural work.

Work through possible causes in order of likelihood rather than assuming an algorithm update.

• Is it real, or a measurement problem? Check whether tracking broke, whether a filter changed, and whether the comparison period is seasonally comparable. This costs five minutes and saves days.
• Is it site-wide or page-specific? A drop confined to one section points at something you changed there; a site-wide drop points at technical or algorithmic causes.
• Technical causes. Check for a stray noindex, a robots.txt change blocking crawlers, a botched migration with missing redirects, server errors, or a certificate problem. These are the most common causes of a sharp drop and the most fixable.
• Manual actions and Search Console messages — check immediately.
• Algorithm update. Compare the drop date against known core update dates and industry chatter. If it aligns and competitors moved too, the cause is likely algorithmic.
• Competitive or SERP change. Someone outranked you, or Google added a feature that pushed organic results down.

Note: Use Search Console's impressions and average position rather than traffic alone. Impressions steady with clicks falling means a SERP or title change, while impressions falling means a ranking or indexing problem — that distinction saves a great deal of wasted work.

Give a framework, because SEO generates infinite possible tasks and the skill is choosing.

Prioritise on impact against effort:

• Fix anything blocking indexing first. A page Google cannot crawl or index earns nothing regardless of how good it is. This always outranks optimisation work.
• Then pages already close to ranking. A page at position 8-15 with good impressions needs far less work to reach page one than a new page needs to rank at all. Search Console makes these easy to find, and it is the highest-return routine task in SEO.
• Then high-commercial-intent pages. Ranking for a term that converts is worth more than ranking for one with ten times the volume and no intent.
• Content updates before new content. Refreshing pages that have decayed is usually cheaper and faster than earning authority for something new.
• Structural work — internal linking, site architecture, templates — because it compounds across many pages at once.

Note: Mention that you factor in implementation reality. A technically ideal fix requiring six months of developer time may be worth less than three smaller changes you can ship next week. Working within constraints is what makes an SEO effective in-house.

Sources, in order of reliability: Google's own documentation and Search Central blog, Google's own statements from people such as the Search Liaison, then established industry publications, then practitioner testing. Much of what circulates as SEO advice is repeated assertion rather than evidence.

How to evaluate a claim:

• Is there evidence, or just confidence? Ask what was tested, on what sample, and over what period. A single site improving after a change proves nothing — many things change simultaneously.
• Correlation is not causation. Ranking studies routinely find that top-ranking pages share a trait; that does not mean the trait causes ranking.
• Does it align with Google's stated purpose? Tactics that make a page genuinely better for users are durable; tactics that exploit a mechanism are temporary and eventually penalised.
• Test on your own site where you can, ideally on a subset of pages, and measure over enough time to exclude noise.

Note: Being able to name a widely-repeated SEO belief you consider unsupported — keyword density targets, or a specific optimal word count — and explain why, is a strong differentiator. It shows you think rather than repeat.

Interviewers ask this because migrations are where SEO most often loses value overnight. Structure your answer around three phases (before, during and after launch) and show that you ran it as a project with owners and checkpoints, not as a redirect list written the night before.

• Context — say what changed: domain, CMS, URL structure or design only. Each carries a different level of risk. Changing the domain and the URL structure at the same time is the riskiest combination.
• Before launch — a full crawl of the old site; an export of top pages by clicks, conversions and backlinks; a one-to-one redirect map (each old URL to its closest equivalent, never everything to the homepage); and a benchmark of rankings and Search Console data. Mention checking the staging site for leftover noindex tags, a blocking robots.txt, missing canonicals, and content or internal links that were dropped in the new templates.
• Launch day — 301s live, staging protections removed from production, the new XML sitemap submitted, the Change of Address tool used if the domain moved, and the old URL list crawled to confirm every redirect lands on a 200 page in one hop.
• After launch — daily checks for 404 spikes, redirect chains and Page Indexing changes, log files confirming Googlebot is fetching the new URLs, and a weekly traffic comparison against the benchmark.

Result: give numbers and be honest about the dip. For example: "Organic sessions fell about 8% for three weeks, then recovered to 5% above baseline by week eight. The 404 report helped us catch 300 unmapped product URLs in the first 48 hours."

Note: Close with what you would do differently. Interviewers like to hear lessons such as keeping redirects in place for at least a year, keeping the old domain registered, and never launching on a Friday.

This question tests influence without authority. SEO specialists rarely own the code, so the interviewer wants to see that you persuade with evidence and specifics rather than escalating or quoting "Google best practice" at people.

• Understand the objection first — pushback usually has a real cause: sprint capacity, performance risk, a design system constraint, or a past SEO request that achieved nothing. Ask what it would take before arguing.
• Translate into business impact — "these 4,000 category pages are not indexed and they drive 30% of organic revenue on competitor sites" lands better than "the canonicals are wrong". Size the opportunity in traffic and revenue with a range, not a promise.
• Make it easy to build — write a ticket with the exact change, examples of correct and incorrect output, and acceptance criteria a QA engineer can test, such as "the rendered HTML contains a self-referencing canonical on every paginated URL".
• Offer options — a smaller first step, a test on one template or section, or a fix bundled into work already planned. Being flexible on the how while holding firm on the outcome builds trust.
• Close the loop — report the result back to the team that built it. Engineers who see their change lift traffic are far more willing next time.

Example structure: "Engineering declined server-side rendering for product pages because of the cost. I showed that Google had indexed only 40% of them and that the missing ones had no rendered description. We agreed to pre-render only the product description and price block. Indexed pages rose to 85% in two months."

Note: Avoid framing developers as blockers. Interviewers listen for respect and collaboration, and the best answers show you learned something about the engineering constraint too.

Leadership funds what it can measure. A strong answer shows you moved the conversation from rankings and traffic to revenue, cost and incrementality, while being honest about what SEO data cannot prove.

• Start from the business metric — revenue, leads, sign-ups or pipeline from organic search, ideally non-brand organic, because brand search mostly reflects demand that other channels created.
• Put a value on traffic — conversions multiplied by average order value or lead value. As a secondary view, estimate what the same clicks would cost in paid search at current CPCs. Present that as a comparison, not as money saved.
• Compare against a forecast — before a project, forecast traffic from search volume, realistic click-through by position and your conversion rate. Afterwards, report actual against forecast. This builds credibility over time.
• Show incrementality where possible — for template changes, run a split test on groups of similar pages, or compare treated sections with untouched control sections. This separates your work from seasonality and algorithm updates.
• Report cost — content, tools, agency and engineering time, so ROI is a real ratio, and remind people that organic returns compound after the spending stops.

Example: "I built a monthly one-page report: non-brand organic revenue, share of total revenue, cost of the programme, and three leading indicators (indexed pages, top-10 keywords, impressions). After a year, non-brand organic revenue was up 42% on a budget equal to six weeks of our paid search spend, and the CFO approved two more writers."

Note: Mention attribution limits openly. Last-click models undercount SEO's role early in the journey, so show assisted conversions or path data alongside last-click figures rather than inflating the numbers.

The interviewer wants to see a repeatable process that connects business goals to search demand, not a list of blog posts you happened to write. Walk through the stages in order.

1. Goal and audience — what the content must achieve (leads, product sign-ups, brand awareness) and who the reader is. Mention inputs beyond keyword tools: sales call notes, support tickets, and the questions customers actually ask.
2. Demand research — seed topics expanded with a keyword tool, Search Console queries and People Also Ask, then grouped by search intent. Explain that you checked the current results for each group to see what format Google rewards: a guide, a tool, a comparison or a product page.
3. Structure — organise topics into clusters, each with a pillar page and supporting articles, so internal links and topical depth develop together rather than as scattered posts.
4. Gap analysis — compare against two or three competitors to find topics they rank for and you do not, and topics nobody covers well.
5. Prioritisation — score each topic on business value, realistic ranking difficulty for your site, and effort. Topics close to the product with moderate difficulty usually go first because they convert and prove the programme early.
6. Production and quality — briefs, subject-matter experts for accuracy and first-hand experience, an editorial checklist, and an update schedule.

Result example: "We launched with three clusters and 36 articles over six months. Organic sign-ups went from near zero to 18% of all trials, and the cluster closest to our pricing page converted at three times the site average."

Note: Say what you stopped doing as well. Dropping high-volume topics that brought traffic but no customers shows judgement that interviewers value.

Manual actions are applied by human reviewers at Google and are reported in Search Console, which makes them different from an algorithmic drop. Show that you confirmed the diagnosis, fixed the cause thoroughly and communicated well. If you have not faced one, say so and describe exactly how you would handle it.

• Confirm — open the Manual actions report. Note the type (for example unnatural links to your site, thin content with little added value, user-generated spam, or structured data issues) and whether it is site-wide or partial. If the report is empty, the drop is algorithmic and the process is different.
• Find the cause — for link actions, export links from Search Console and a third-party tool and flag paid links, link networks, exact-match anchor patterns and old agency work. For content actions, identify the thin, scraped or doorway pages.
• Fix, do not hide — request removal of bad links and keep records of your outreach. Disavow what cannot be removed, usually at domain level. For content, improve, merge or remove the pages rather than just noindexing a few.
• Reconsideration request — explain what happened, what you changed, and how you will prevent it happening again, with evidence such as the outreach log, the disavow file summary and the list of removed pages. Be factual and take responsibility.
• Prevent recurrence — a link-buying policy for agencies, UGC moderation, or content quality gates.

Example: "A previous agency had bought around 600 links. We removed 140 through outreach, disavowed 410 domains and documented everything. The first request was rejected for incomplete cleanup. The second was approved after five weeks, and rankings recovered over the following two months."

Note: Point out that revoking an action does not restore rankings that were propped up by the bad links. Setting that expectation early protects your credibility.

Three distinct stages, and a page must pass each before it can appear in results.

• Crawling — Googlebot discovers URLs by following links, reading sitemaps, and revisiting known pages, then fetches them. Blockers: robots.txt disallow rules, no internal links pointing to the page, server errors, or a slow site consuming the crawl budget.
• Indexing — Google renders the page, understands its content, and decides whether to store it. Crawled does not mean indexed. Blockers: a noindex tag, a canonical pointing elsewhere, duplicate or thin content, or content that only appears after JavaScript execution which fails.
• Ranking — for a given query, Google orders indexed pages using hundreds of signals: relevance to the query, content quality, links, user location and history, page experience, and freshness.

Why the distinction matters practically: the diagnosis and fix are completely different at each stage. Search Console's Page Indexing report tells you which stage failed — "Discovered, currently not indexed" is a very different problem from "Crawled, currently not indexed", and both differ from a page indexed but ranking poorly.

Note: Add that Google renders JavaScript, but rendering is queued and resource-intensive. Content that requires JavaScript may be indexed late or incompletely, which is why server-side rendering or static generation is safer for content that must rank.

• Technical SEO — making the site crawlable, indexable, and fast. Site architecture, robots.txt, XML sitemaps, canonical tags, redirects, structured data, HTTPS, mobile-friendliness, Core Web Vitals, and JavaScript rendering. It is the foundation: without it, nothing else can work.
• On-page SEO — optimising the content and HTML of individual pages. Search intent matching, content quality and depth, title tags and meta descriptions, heading structure, internal linking, image alt text, and URL structure. This is where you have the most direct control.
• Off-page SEO — signals from elsewhere, principally backlinks from other sites, which remain among the strongest ranking factors. Also brand mentions, digital PR, and for local businesses the Google Business Profile and citations.

How they relate: technical SEO is necessary but not sufficient — a perfectly crawlable site with poor content ranks for nothing. On-page is where most sites have the largest unexploited opportunity. Off-page is the hardest to influence and the hardest for competitors to replicate, which is why it carries weight.

Note: The right prioritisation to state: fix technical blockers first because they cap everything else, then on-page because it is within your control, then off-page because it is slow and expensive. Investing in link building while pages carry noindex tags is a real and common mistake.

The process:

• Start from the business, not the tool. What does the site sell, and what problems does it solve? Seed terms come from products, customer language, and sales conversations.
• Expand with Keyword Planner, Search Console (which shows terms you already get impressions for — often the fastest source of opportunity), autocomplete, People Also Ask, and third-party tools.
• Analyse competitors to find terms they rank for that you do not.
• Qualify each term on search volume, difficulty relative to your site's authority, and — most importantly — commercial value.

Search intent is what the user actually wants, and matching it is more important than the keyword itself. Four types:

• Informational — "what is working capital". Wants an explanation. Serve an article.
• Navigational — "jobaaj login". Wants a specific site.
• Commercial investigation — "best accounting software". Comparing options. Serve a comparison or review.
• Transactional — "buy tally erp9". Ready to act. Serve a product or pricing page.

Note: The practical method is to search the term and look at what ranks. If the first page is all listicles, Google has decided that query wants a listicle, and a product page will not rank however well optimised. Intent mismatch is the most common reason a well-written page fails to rank, and reading the SERP is how you avoid it.

• Title tag — the clickable headline in search results and the strongest single on-page signal. Aim for roughly 50-60 characters before truncation. Put the primary keyword near the front, make it a compelling reason to click, and keep it unique across every page. Brand at the end if there is room.
• Meta description — not a ranking factor, but it heavily influences click-through rate, which matters. Around 150-160 characters, describing what the page offers with a reason to click. Google frequently rewrites it, particularly when it does not match the query — so write it for the searcher rather than for the algorithm.
• Header tags (H1-H6) — structure the content for readers and give context to search engines. One <h1> per page describing the topic, then <h2> for main sections and <h3> beneath them. Use them in order and for structure, never for styling — that is CSS's job.

The optimisation that actually pays: find pages in Search Console with high impressions and low click-through rate. Those are pages Google already ranks where the title is failing to earn the click, and rewriting them produces results faster than almost anything else in SEO.

Note: Avoid keyword stuffing in any of these. Repeating a term in the title looks spammy to users, suppresses clicks, and has not helped rankings for many years.

Three technical controls that are frequently confused, and confusing them causes serious problems.

• robots.txt — controls crawling. It tells crawlers which paths not to fetch. Critically, it does not control indexing: a blocked URL can still appear in results if other pages link to it, showing without a description. Never use robots.txt to keep a page out of the index — because blocking the crawl means Google cannot see the noindex tag either.
• noindex meta tag — controls indexing. This is the correct way to keep a page out of results. The page must remain crawlable for it to work.
• Canonical tag — handles duplication. It tells Google which version of similar pages is the preferred one, consolidating ranking signals onto it. Essential for e-commerce filters and parameters, printer-friendly versions, and pages reachable by multiple URLs. It is a hint rather than a directive; Google may choose differently.
• XML sitemap — aids discovery. A list of URLs you want indexed, submitted through Search Console. Useful for large sites, new sites, and pages with few internal links. It only includes canonical, indexable URLs — listing a noindexed page sends contradictory signals.

Note: The classic mistake is blocking a directory in robots.txt to remove it from search, then finding the URLs still listed. Say that, and it demonstrates you understand the crawl-index distinction rather than reciting definitions.

Core Web Vitals are Google's user experience metrics, part of the page experience signals:

• LCP (Largest Contentful Paint) — how long until the main content renders. Target under 2.5 seconds. Usually driven by server response time, render-blocking resources, or a large unoptimised hero image.
• INP (Interaction to Next Paint) — responsiveness to user input, which replaced First Input Delay in 2024. Target under 200 milliseconds. Caused by long JavaScript tasks blocking the main thread.
• CLS (Cumulative Layout Shift) — visual stability. Target under 0.1. Caused by images without dimensions, ads or embeds injected above existing content, and web fonts causing reflow.

How much they matter for ranking: they are a real but modest signal, and Google has described them as a tiebreaker between pages of comparable relevance. They will not rescue poor content, and excellent content will still rank with mediocre vitals. Being honest about this is important — many candidates overstate it.

Where the real value lies is conversion. A faster, more stable page produces measurably better engagement and revenue regardless of ranking, and that is the stronger business argument.

Note: Distinguish lab data from field data. PageSpeed Insights lab scores are diagnostic; the Chrome User Experience Report field data from real users is what Google actually uses. Optimising for a lab score while real users on slow connections still struggle is a common trap.

Backlinks remain among the strongest ranking signals, functioning as votes of confidence. Quality matters far more than quantity — one link from an authoritative, topically relevant site outweighs hundreds from low-quality directories.

Legitimate approaches:

• Creating genuinely linkable assets — original research, data, tools, or definitive guides. The most durable approach because it earns links passively.
• Digital PR — newsworthy content pitched to journalists.
• Guest contributions to relevant publications, written to be genuinely useful.
• Broken link building — finding dead links on relevant pages and offering your resource as a replacement.
• Reclaiming unlinked brand mentions.

White hat versus black hat:

• White hat follows Google's guidelines and optimises for users. Slower, durable, and safe.
• Black hat exploits the algorithm: buying links, private blog networks, hidden text, cloaking (showing different content to crawlers than users), doorway pages, and scraped or spun content. It can work briefly and risks a manual action or algorithmic penalty that is expensive and slow to recover from.
• Grey hat sits ambiguously between — aggressive tactics not explicitly prohibited but clearly against the spirit.

Note: The decisive argument against black hat is business risk, not ethics. Recovery from a penalty can take many months of lost revenue, and anyone recommending it is transferring risk from themselves to the client.

Structured data is machine-readable markup that explicitly describes what a page's content means, using the vocabulary at schema.org. Rather than leaving Google to infer that "4.5" is a rating and "₹2,499" is a price, you state it.

JSON-LD is the recommended format — a script block in the page rather than attributes woven through the HTML, so it is far easier to maintain and does not break when the design changes.

Why use it:

• Rich results. The main practical benefit. Star ratings, prices and availability, FAQ accordions, recipe cards, event details, and breadcrumbs all occupy more space in results and materially improve click-through rate.
• Clarity of meaning, which helps Google understand entities and relationships — increasingly relevant as search becomes more entity-based.
• Eligibility for specific features such as Google Shopping listings or job postings, which require it.

Common types: Organization, LocalBusiness, Product, Article, FAQPage, HowTo, Event, Recipe, BreadcrumbList, and Review.

Note: Three important caveats. Structured data is not a direct ranking factor — it affects presentation, not position. The markup must match visible page content, and marking up content users cannot see is a guidelines violation that can trigger a manual action. And rich results are never guaranteed; eligibility is not entitlement. Validate with the Rich Results Test and monitor the Enhancements reports in Search Console.

Google's own tools — free, authoritative, and non-negotiable:

• Google Search Console — the most important tool in SEO. Actual query data with impressions, clicks, position, and CTR; the Page Indexing report showing exactly why pages are not indexed; the URL Inspection tool for live testing; Core Web Vitals field data; manual action notices; and sitemap submission. Nothing else provides Google's own view of your site.
• Google Analytics — behaviour after the click, and conversions from organic.
• PageSpeed Insights — lab and field performance data.
• Rich Results Test — structured data validation.

Third-party tools:

• Screaming Frog — a desktop crawler for technical audits: broken links, redirect chains, duplicate titles, missing tags, orphan pages. Essential for any site audit.
• Ahrefs or Semrush — backlink analysis, competitor research, keyword difficulty, and rank tracking. Their traffic figures are estimates, which matters when reporting.
• Ahrefs Webmaster Tools as a free option for backlinks and basic auditing.

Note: The framing that impresses: tools produce data, not decisions. A Screaming Frog crawl of a large site returns thousands of "issues", most of which do not matter. The skill is knowing which findings affect indexing or rankings and which are noise — and being able to say that separates practitioners from people who send clients a raw audit export.

Local SEO targets searches with geographic intent — "chartered accountant near me", "dentist in Pune" — and competes for a different piece of the results page: the local pack of three map listings that appears above organic results.

What differs from national SEO:

• The Google Business Profile is the single most important asset, not the website. Complete it fully: correct category (which carries substantial weight), accurate hours, service areas, photos, products or services, and regular posts.
• NAP consistency — Name, Address, Phone identical across your site, the Business Profile, and every directory citation. Inconsistency actively damages local rankings, and this is the most common problem in local SEO audits.
• Reviews matter directly. Volume, average rating, recency, and responses all influence local ranking, and they influence conversion even more. Actively requesting reviews and responding to all of them is core local SEO work, not an optional extra.
• Proximity is a ranking factor you cannot optimise. A searcher's physical distance from the business affects what they see, which means results genuinely differ by location and rank tracking must account for it.
• Location pages on the website for each area served, with genuinely distinct content rather than a template with the city name swapped.

Note: LocalBusiness structured data with address, hours, and geo coordinates reinforces the signals. And for multi-location businesses, a separate Business Profile per physical location is required — one profile cannot serve several branches.

They act at different stages. robots.txt controls crawling; noindex controls indexing. Confusing the two is one of the most common technical SEO mistakes.

• robots.txt Disallow — tells compliant crawlers not to fetch the URL. It does not remove the URL from the index. If other pages link to it, Google can still index the bare URL and show it without a description. Use it to stop crawlers wasting resources on infinite parameter combinations, internal search results or admin areas.
• noindex — delivered as <meta name="robots" content="noindex"> in the HTML, or as an X-Robots-Tag: noindex HTTP header, which is the only option for PDFs and other non-HTML files. Google must crawl the page to see the directive, and then drops the page from results.

Why not combine them: if a URL is disallowed, Googlebot never fetches it, so it never sees the noindex and the URL can stay indexed indefinitely. The correct removal sequence is: allow crawling, add noindex, wait until the URL drops out (check with URL Inspection), and only then block it if crawl waste is a genuine concern.

Other points worth making:

• robots.txt is public and advisory. It is not a security control, so protect private content with authentication.
• Blocking CSS or JavaScript files in robots.txt can stop Google rendering pages correctly.
• For urgent cases, the Search Console Removals tool hides a URL temporarily (for about six months) while the permanent fix takes effect.

Note: Google has said that pages left on noindex for a long time are crawled less often and their links may eventually stop being followed, so noindex is not a reliable way to keep link equity flowing through a page.

The codes differ on two axes: whether the move is permanent or temporary, and whether the browser must keep the original HTTP method (for example, a POST stays a POST).

How Google treats them: 301 and 308 are strong signals that the target should become the canonical URL, so the old URL is replaced in results. 302 and 307 are weak signals, so Google usually keeps the original URL indexed. If a "temporary" redirect stays in place for a long time, Google may eventually treat it as permanent. Google has also said that server-side redirects do not lose PageRank, so there is no reason to avoid a 301 for fear of losing link value.

Other redirect types:

• Meta refresh — an instant meta refresh is interpreted as permanent, a delayed one as temporary. Use it only when you cannot configure the server.
• JavaScript redirects — Google follows them only if rendering succeeds, so they are the least reliable option.

Common mistakes: using 302 for a permanent migration because it was the framework default, redirecting removed pages to the homepage (often treated as a soft 404), and leaving redirects that point to other redirects.

Note: If you see a "307 Internal Redirect" in Chrome DevTools on an HTTPS site, it usually comes from the browser applying HSTS, not from your server. Check the real response with curl before reporting it as a bug.

• Redirect chain — a URL that redirects to another redirect before reaching the final page, for example http://example.com/shoes to https://example.com/shoes to https://www.example.com/shoes to https://www.example.com/shoes/. Chains build up from protocol, host and trailing-slash rules stacked on top of one another, and from repeated migrations.
• Redirect loop — URLs redirecting back to each other so no page is ever reached. They usually come from conflicting rules at different layers (CMS, web server, CDN), or from redirects based on cookies or location.

Why they matter: every hop adds latency for users and uses crawl resources. Googlebot follows a limited number of hops (Google documents up to 10) before giving up, and long chains make it slower for signals to consolidate on the final URL. Loops make a page unreachable, and Search Console reports them as redirect errors.

How to find them:

• Crawl the site with a crawler such as Screaming Frog or Sitebulb and export the redirect chains report.
• Crawl the old URL lists from previous migrations and backlink exports in list mode, because chains often start at URLs no longer linked internally.
• Check individual URLs with curl -sIL https://example.com/page to see each hop and status code.
• Review the Page Indexing report for "Redirect error" and server logs for Googlebot requests that end in 3xx responses.

How to fix them: rewrite rules so every legacy URL points directly to its final destination in one hop; combine protocol, host and slash normalisation into a single rule; update internal links, canonicals, hreflang and sitemaps to use final URLs only; and resolve loops by deciding which layer owns each rule.

Note: Internal links pointing to redirected URLs are the easiest fix and are often overlooked. Updating them removes the hop entirely instead of just shortening the chain.

A declared canonical is a hint, not a directive. Google chooses a canonical from several signals: redirects, the canonical link element, sitemap inclusion, internal links, a preference for HTTPS, hreflang references and how similar the content is. If those signals disagree, Google may pick a different URL. Search Console shows this as "Duplicate, Google chose different canonical than user", and URL Inspection shows both the user-declared and the Google-selected canonical.

Common reasons a canonical is ignored:

• The pages are not really duplicates — for example, canonicalising page 2 of a category to page 1, or a red product variant to a blue one with different content.
• The target is not indexable — it returns a 404, redirects elsewhere, is noindexed or is blocked by robots.txt.
• Conflicting signals — internal links, the XML sitemap or hreflang point to a different version from the one declared.
• Implementation errors — several canonical elements on one page, a canonical placed in the body, relative URLs that resolve wrongly, or a canonical that JavaScript changes after the initial HTML loads.
• Protocol or host mismatch — declaring an HTTP URL when the site serves HTTPS.

How to make your choice stick:

• Use one absolute canonical, <link rel="canonical" href="https://www.example.com/page/">, in the head of the initial HTML.
• Align every signal: link internally only to the canonical, list only canonicals in sitemaps, and point hreflang at canonicals.
• Use a 301 instead of a canonical when users never need the duplicate URL. A redirect is a much stronger signal.
• Make sure the canonical URL returns 200 and is indexable.

Note: Self-referencing canonicals on every indexable page are a cheap defence against tracking parameters and scraped copies, and they are recommended practice even when no duplicate exists yet.

hreflang tells Google which language or regional version of a page to show a particular user. It does not improve rankings on its own. It swaps the right version into results and reduces duplicate-content problems between similar regional pages.

Three ways to implement it (choose one per site): link elements in the head, HTTP headers (useful for PDFs), or XML sitemap annotations (easiest to maintain on large sites). A set for one page looks like this:

<link rel="alternate" hreflang="en-in" href="https://example.com/in/pricing/" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/uk/pricing/" />
<link rel="alternate" hreflang="hi-in" href="https://example.com/hi/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing/" />

Rules that must hold:

• Every version lists all versions, including itself. Annotations must be reciprocal; if the UK page lists the India page but the India page does not list the UK page back, the pair can be ignored.
• Codes are an ISO 639-1 language code, optionally followed by an ISO 3166-1 alpha-2 region: en-gb, not en-uk. A region on its own is invalid.
• Every URL in the set must be the canonical, indexable version returning 200.
• x-default names the fallback page for users who match no listed version, often a language selector or the global page.

Mistakes that break it: canonicalising all language versions to one "main" version (which tells Google to drop the others), missing return links after a new locale is added, pointing hreflang at redirected URLs, invalid codes, and serving machine-translated pages of poor quality.

Note: Avoid automatic redirects based on IP address. Googlebot mostly crawls from US addresses, so geo-redirects can stop it from ever seeing your other regional versions. Offer a banner or selector instead.

The structure decides how strongly you signal a target country, how authority is shared between regions, and how expensive the setup is to run.

How to choose:

• Subdirectories suit most businesses entering new markets, because each new section benefits from the existing domain's links from day one.
• ccTLDs make sense when local trust really matters (some markets prefer local domains), when there are legal or tax reasons, or when regional businesses operate independently with their own budgets.
• Subdomains are usually chosen for technical or organisational reasons rather than SEO benefit.

Whatever you choose: use hreflang between equivalent pages, localise properly (currency, prices, shipping, contact details, spelling and examples, not just translation), earn some local links, and avoid forced IP redirects.

Note: Separate language from country. A Spanish-language section can serve several countries with one version, while India might need English and Hindi versions for one country. Map both dimensions before deciding the URL structure.

On a small, well-linked site a sitemap is a convenience. On a large site it becomes a discovery mechanism and a diagnostic tool.

• Size limits — each sitemap may hold up to 50,000 URLs or 50 MB uncompressed. Larger sites use a sitemap index file that lists the child sitemaps, and you submit the index.
• Only canonical, indexable URLs — every URL should return 200, be self-canonical and not be noindexed or blocked. Listing redirects, 404s or parameter duplicates sends conflicting signals and wastes crawling.
• Accurate lastmod — Google uses lastmod when it is consistently accurate and ignores it on sites where it is not. Update it only for meaningful content changes, never to the time the file was generated. Google ignores priority and changefreq.
• Segment by type — separate sitemaps for products, categories, articles and locations. Search Console then reports indexing per sitemap, so you can see immediately that, for example, 92% of categories are indexed but only 55% of products.
• Keep them fresh automatically — generate sitemaps from the database or CMS so new pages appear within hours and removed pages disappear.
• Submission — submit in Search Console and reference the index in robots.txt with a Sitemap: line. Google has retired its sitemap ping endpoint, so rely on these methods and accurate lastmod values.
• Specialised sitemaps — image, video and news sitemaps add metadata for those search features, and hreflang annotations can be managed inside sitemaps.

Using it as a diagnostic: compare the URLs in your sitemaps with your crawl and your log files. Sitemap URLs that are never crawled suggest weak internal linking or quality problems. Crawled URLs missing from the sitemap may be orphans or unwanted duplicates.

Note: A sitemap helps discovery but does not guarantee indexing. If important sitemap URLs sit at "Discovered, currently not indexed", the fix is usually internal linking or content quality, not resubmitting the sitemap.

Site architecture is how pages are grouped and linked together. It decides how easily crawlers discover pages, how link equity flows through the site, and how clearly Google understands what each section is about.

• Shallow and logical hierarchy — home, then category, then subcategory, then detail page. Click depth is the number of clicks needed to reach a page from the homepage. Important pages should be reachable within about three clicks; pages buried at depth six or more tend to be crawled less often and rank weakly.
• Organise around demand — categories should mirror how people search, which you validate with keyword research, rather than mirroring internal team structure or warehouse codes.
• Hub pages — category and topic hubs that link to every child page give each section a strong, crawlable entry point.
• Breadcrumbs — they reinforce hierarchy for users and crawlers and can be marked up with BreadcrumbList structured data.

URL structure best practices:

• Short, readable and descriptive: /laptops/gaming/ rather than /cat.php?id=4471.
• Lowercase letters with hyphens between words; avoid spaces, underscores and session IDs.
• One URL per piece of content, with consistent rules for trailing slashes, www and HTTPS, enforced by redirects.
• Do not over-nest folders. Mirroring the hierarchy is helpful, but a six-folder path adds nothing.
• Keep URLs stable. Every change needs redirects, so avoid putting dates or volatile category names into URLs unless they are genuinely part of the content.

How to measure it: a crawler reports click depth per URL and shows orphan pages. Compare depth with performance; if top-selling products sit at depth five, add links from hub pages, “popular products” modules or the navigation.

Note: Flat does not mean linking everything from the homepage. A mega-menu with 800 links dilutes the signals it sends. The goal is a clear hierarchy in which every page has a short, relevant path to it.

Internal links are the signal you control completely. They help Google discover pages, understand how pages relate to each other through anchor text, and judge which pages matter most on your site.

Principles of a good strategy:

• Link from strength to need — pages with many backlinks or high traffic should link to important pages that need a boost, such as a new product category.
• Contextual links beat boilerplate — a link inside relevant body copy carries clearer meaning than the same link repeated in a footer on every page.
• Descriptive anchor text — “GST registration process” tells Google far more than “click here”. Vary it naturally; keyword-stuffed internal anchors read badly and add nothing.
• Cluster linking — pillar pages link to every supporting article, and supporting articles link back to the pillar and to closely related siblings.
• Crawlable links — use a real anchor element with an href. Links that exist only as JavaScript click handlers may not be followed.

Orphan pages are pages with no internal links pointing to them. Google can find them only through sitemaps or external links, and they usually perform poorly.

1. Find them — crawl the site, then compare the crawled URL list with URLs from the XML sitemaps, analytics landing pages, Search Console and server logs. Anything in those sources but not in the crawl is orphaned.
2. Decide — if the page is valuable, link to it from its parent category, a hub page or related articles. If it is obsolete, redirect it to the closest relevant page or remove it.
3. Prevent — add CMS rules so every new page must have a parent, and include orphan checks in regular audits.

Note: A quick win interviewers like: use Search Console to find pages ranking in positions 8 to 20, then add contextual internal links to them from relevant, well-linked pages. It often moves them within weeks at almost no cost.

Start by confirming the problem in field data (the Search Console Core Web Vitals report or CrUX), which groups similar URLs, then reproduce it in lab tools such as Lighthouse and the Chrome DevTools Performance panel. The “good” thresholds, measured at the 75th percentile of page loads, are LCP up to 2.5 seconds, INP up to 200 milliseconds and CLS up to 0.1.

Largest Contentful Paint (loading) — find the LCP element, usually a hero image or headline, and break its time into server response, resource load delay, load duration and render delay.

• Reduce server response time with caching, a CDN and fewer server-side redirects.
• Make the hero image discoverable in the initial HTML, give it high fetch priority, and never lazy-load it.
• Serve compressed, correctly sized images in modern formats such as WebP or AVIF.
• Remove render-blocking CSS and JavaScript; inline critical CSS.

Interaction to Next Paint (responsiveness) — find slow interactions with field data or the Performance panel.

• Break up long tasks (over 50 ms) and yield to the main thread so input can be handled.
• Reduce and defer JavaScript, especially third-party tags, chat widgets and A/B testing scripts.
• Keep event handlers light: show visual feedback first and do the heavy work afterwards.
• Reduce DOM size and avoid forced layout recalculation inside handlers.

Cumulative Layout Shift (visual stability) — use the Layout Shift regions in DevTools.

• Set width and height or aspect-ratio on images, videos and iframes.
• Reserve space for ads, embeds and cookie banners before they load.
• Never insert content above existing content unless the user asked for it.
• Use font fallbacks with matched metrics to reduce shifts when web fonts swap in.

Note: Fix at template level, not URL by URL, and remember the field data is a 28-day rolling window, so improvements take weeks to show in Search Console. Treat Core Web Vitals as a user experience and conversion project; the ranking effect is real but modest.

• Lab data — a synthetic test run in a controlled environment with a fixed device, network speed and location. Lighthouse, the diagnostics section of PageSpeed Insights and WebPageTest produce lab data. It is repeatable and detailed, which makes it ideal for debugging and for testing a change before release.
• Field data — measurements from real users on their real devices and networks, also called Real User Monitoring. Google's public source is the Chrome User Experience Report (CrUX), which aggregates data from opted-in Chrome users over a rolling 28-day window.

Which one Google uses: for Core Web Vitals as part of page experience, Google uses field data from CrUX, assessed at the 75th percentile. The Search Console Core Web Vitals report is built on the same field data. The Lighthouse performance score is a lab diagnostic and is not a ranking input in itself.

Why the numbers disagree:

• Real users have a mix of devices; a lab test on a throttled mid-range phone may be faster or slower than your actual audience.
• Field data includes cached repeat visits, logged-in states, consent banners and third-party scripts that the lab test may not trigger.
• INP needs real interactions, so it cannot be measured in a standard lab run. Total Blocking Time is the lab proxy that points at the same main-thread problems.
• Low-traffic pages may have no URL-level CrUX data, so tools fall back to origin-level data or group similar pages.

How to use both: use field data to decide whether there is a problem and which templates it affects, and use lab data to find why and to verify fixes before release. For faster feedback than the 28-day CrUX window, collect your own field data with the web-vitals JavaScript library and send it to analytics.

Note: A common interview trap is “our Lighthouse score is 45, so we will lose rankings.” The better answer is to check the field data first; many sites with mediocre lab scores pass Core Web Vitals for real users.

Google processes JavaScript pages in stages: it crawls the URL and reads the initial HTML, places the page in a render queue, renders it with an up-to-date headless Chromium (the Web Rendering Service), and then indexes the rendered HTML and any links found in it. Rendering usually happens quickly now, but it is resource-intensive and can fail if scripts time out, APIs are blocked or errors occur.

What to recommend: for pages that must rank (product, category, article and landing pages), content, links, titles, canonicals and structured data should be present in the server response. Frameworks such as Next.js and Nuxt make this practical. Client-side rendering is fine for logged-in dashboards and interactive tools that do not need to rank.

How to verify: use the live test in URL Inspection to view the rendered HTML and screenshot; compare “view source” with the DevTools Elements panel; and crawl with JavaScript rendering both on and off to see what content exists only after rendering.

Note: Remember crawlers other than Googlebot. Many social preview bots and AI crawlers read only the initial HTML, so server-rendered content protects visibility well beyond Google.

Most JavaScript SEO problems come from assuming Googlebot behaves like a user in a browser. It does not click, scroll or keep state the way people do.

• Links that are not links — navigation built with click handlers on a div or button, or anchors without an href. Google discovers URLs from real anchor elements with resolvable href values.
• Content that needs interaction — text loaded only after a click, a tab switch that triggers an API call, or “load more” buttons. Content hidden with CSS but present in the DOM is fine; content that is never fetched is not.
• Lazy loading tied to scroll events — Googlebot does not scroll like a user. Use native lazy loading or IntersectionObserver so content loads when it enters the viewport.
• Hash-based routing — URLs like /#/products/42 are treated as a single URL because fragments are ignored. Use the History API with real paths.
• Soft 404s in single-page apps — the server returns 200 for every route and the app shows “not found”. Return a real 404 from the server, or add a noindex directive to error views.
• A noindex in the initial HTML that JavaScript removes — if Google sees noindex in the raw HTML, it may skip rendering altogether, so the removal never takes effect.
• Metadata changed by JavaScript — titles, canonicals or hreflang that differ between raw and rendered HTML send mixed signals.
• Blocked resources — scripts, CSS or API endpoints disallowed in robots.txt, so rendering produces an empty page.
• Relying on cookies, local storage or permissions — Googlebot renders statelessly, so content behind a location prompt or stored preference will be missing.
• Infinite scroll without paginated URLs — items beyond the first batch are never discovered.

How to catch them: the rendered HTML and screenshot in URL Inspection, a JavaScript-rendering crawl compared with a non-rendering one, and searching Google for an exact sentence from the page to confirm it was indexed.

Note: The durable fix for most of these is to put critical content and links in the server-rendered HTML. Everything else is a patch.

Testing tools and what each is for:

• Rich Results Test — checks whether a URL or code snippet is eligible for Google's rich result types and shows errors and warnings against Google's requirements, using the rendered page.
• Schema Markup Validator (validator.schema.org) — checks general schema.org syntax, including types Google does not use for rich results.
• Search Console enhancement reports — show valid and invalid items across the whole site for each supported type (products, breadcrumbs, videos and so on). This is where you catch template-wide breakages after a release.
• URL Inspection — confirms which structured data Google detected on the indexed version of a page.

Why valid markup might still not show a rich result:

• Eligibility is not a guarantee — Google decides per query and per page whether a rich result helps the searcher.
• Missing required properties — for example a Product with no offers, review or aggregateRating. Warnings do not block eligibility, but errors do.
• The markup does not match visible content — marking up reviews, prices or FAQs that users cannot see breaks Google's guidelines and can lead to a manual action.
• Restricted or retired features — Google has narrowed or removed some types over time. FAQ rich results, for instance, were limited to well-known authoritative government and health sites, and HowTo rich results were removed. Check the current documentation before promising a feature.
• Site quality — Google may withhold rich results from sites it considers low quality.
• The page is not indexed, or Google has not recrawled it since the markup was added.
• Policy issues — for example, self-serving reviews that a business publishes about itself are not eligible for review stars.

Note: Recommend JSON-LD generated from the same data that renders the visible page, so price, stock and ratings can never drift out of sync with what users see.

E-E-A-T stands for Experience, Expertise, Authoritativeness and Trustworthiness. It comes from Google's Search Quality Rater Guidelines, which human raters use to evaluate search results. Their ratings help Google assess its ranking systems; they do not change rankings for individual sites directly.

• Experience — first-hand experience of the topic: actually using the product, visiting the place or doing the job.
• Expertise — knowledge or skill in the subject, which for some topics means formal qualifications.
• Authoritativeness — being a recognised go-to source for the topic, as shown by what others say about you.
• Trustworthiness — the most important element. Content is accurate, honest and safe, and the site is transparent about who is behind it.

What to say clearly: E-E-A-T is not a single ranking factor or score. Google uses many signals that together align with what E-E-A-T describes, and it matters most for YMYL (“Your Money or Your Life”) topics such as health, finance, legal and safety, where poor information can cause real harm.

How to demonstrate it on a site:

• Clear authorship — named authors with bios, relevant credentials and links to their other work; reviewer credits for expert-checked content.
• Visible first-hand evidence — original photos, test results, screenshots, case data and specific details that could only come from real use.
• Transparency — a detailed About page, address and contact details, an editorial policy, a corrections policy, and disclosure of affiliate relationships.
• Accuracy — cited sources, up-to-date facts and dated revisions.
• Reputation — reviews on independent platforms, press coverage, and links and mentions from respected sites in your field.
• Trust basics — HTTPS, clear refund and privacy policies, and a secure checkout.

Note: Adding an author box does not create expertise. Interviewers respect candidates who say the real work is involving genuine experts and producing first-hand content, and that the visible signals simply make that work apparent.

Google's guidance asks whether content is created primarily to help people or primarily to attract search traffic. Signals that assess helpfulness were once described as a separate “helpful content system” and are now part of Google's core ranking systems. They can affect how a site performs overall, not only individual pages.

Google frames it with “Who, How and Why” questions:

• Who created it? Is the authorship clear, and is the author someone readers would trust on this subject?
• How was it created? Is it clear how products were tested, where data came from, and where automation or AI was used?
• Why was it created? To help an audience you already serve, or to capture queries in a topic you have no connection to?

Warning signs of search-first content: writing to a target word count, summarising other sites without adding anything, covering trending topics unrelated to your audience, mass-producing pages with AI or templates (which can fall under the scaled content abuse spam policy), and content that leaves readers needing to search again.

How to run an audit:

1. Inventory — list every indexable URL with its clicks, impressions, conversions, backlinks and last-updated date.
2. Flag at-risk sections — pages with no clicks in 12 months, near-duplicate programmatic pages, off-topic content and thin affiliate reviews.
3. Review manually — sample pages and rate each for originality, first-hand experience, accuracy, how well it satisfies the intent, and clear authorship.
4. Act — improve pages worth keeping, consolidate overlapping ones, and remove or noindex pages that serve no audience.
5. Monitor — recovery typically takes months and often coincides with later core updates, so set expectations.

Note: Google has said AI-generated content is not against its guidelines in itself; what matters is whether it is helpful and original. A strong answer focuses on value and editorial oversight, not on the tool used.

A topic cluster is a group of interlinked pages that together cover a subject in depth. It is built around a pillar page, a broad overview of the main topic, supported by cluster pages that each go deep on one subtopic or question.

Example for a careers site:

• Pillar: “Data analyst career guide”, covering the role, skills, salary, tools and career path.
• Cluster pages: “SQL interview questions for data analysts”, “Data analyst salary in India”, “Excel vs Power BI for analysts”, “How to build a data analyst portfolio”, “Data analyst vs data scientist”.
• Linking: the pillar links to every cluster page, each cluster page links back to the pillar with descriptive anchor text, and closely related cluster pages link to one another.

Why it helps:

• Relevance and depth — covering a subject comprehensively helps search engines understand that the site is a strong source on it. “Topical authority” is an industry term rather than a named Google metric, but depth and consistency of coverage clearly help.
• Link equity flow — links earned by any page in the cluster strengthen the others through internal links.
• Less cannibalisation — planning a cluster forces you to assign one intent to each page, so pages do not compete for the same query.
• Better user journeys — readers move naturally from the overview to specifics, which increases engagement and conversions.

How to build one: choose a topic central to the business, run keyword research and group queries by intent (each intent group becomes one page), check which formats rank for each group, map the pillar and cluster pages, publish the pillar early, and add internal links as each cluster page goes live.

Note: Clusters are not just a linking pattern. If the cluster pages are thin, the structure will not rescue them. Depth and quality on each page come first, and the architecture amplifies them.

Keyword cannibalisation happens when two or more pages on the same site target the same query and the same search intent, so they compete with each other. Google may alternate between them, rank neither strongly, or show the less useful one. Signals such as links and relevance are split instead of concentrated.

It is not always a problem. Two URLs ranking for a query can be fine when they serve different intents, for example a category page and a buying guide, or when both rank well. The problem is when rankings fluctuate and neither page performs.

How to identify it:

• Search Console — in the Performance report, filter by a query and open the Pages tab. Several URLs sharing impressions for one query, with average position swapping over time, is the classic pattern.
• Rank tracking tools — flag keywords where the ranking URL keeps changing.
• Content inventory — look for near-identical titles and H1s, for example one post titled “Best CRM software 2024” and another titled “Top CRM tools” from the following year.

How to fix it, depending on the cause:

• Consolidate — merge the pages into the strongest one, add the best content from the others, and 301 redirect the weaker URLs. This is the most common and most effective fix.
• Differentiate — if both pages deserve to exist, retarget one to a distinct intent or subtopic and rewrite its title, headings and content to match.
• Canonicalise — when near-duplicates must stay live for users, such as print versions or filtered views, point them to the primary version.
• Fix internal signals — make internal links with that anchor text point to the chosen page, and remove the weaker page from navigation if appropriate.
• Noindex — for pages that are useful to users but have no search value, such as tag archives.

Note: Prevent it with a keyword-to-URL map that writers check before creating content. It is far cheaper than cleaning up hundreds of overlapping blog posts later.

What makes a backlink valuable:

• Relevance — the linking site and page are about a related topic. A link from an HR publication to a careers site outweighs one from an unrelated directory.
• Authority and real audience — the site has its own links and genuine traffic. Third-party scores such as Domain Authority or Domain Rating are useful for comparison, but they are vendor metrics, not Google's.
• Editorial placement — the link was given by choice inside the body content, not bought, swapped, or placed in a footer, sidebar or author bio at scale.
• Natural anchor text — a mix of brand, URL and descriptive anchors. A profile dominated by exact-match commercial anchors is a warning sign.
• Link attributes — nofollow, sponsored and ugc are treated as hints. Such links may still help discovery and brand awareness, but they pass little or no ranking credit.
• Referral traffic — a link that sends real visitors is almost always a good one.

When to use the disavow tool: Google says most sites never need it, because its systems already identify and ignore most spammy links. Use it when:

• you have a manual action for unnatural links, or
• you know of a significant number of paid or scheme links pointing at the site (for example from a previous agency) that could lead to one, and you cannot get them removed.

When not to use it: for random low-quality scraper links, for links a tool labels “toxic” without further review, or as a reflex after a traffic drop. Disavowing good links can hurt performance.

How it works: upload a plain-text file to the disavow tool in Search Console with one URL or domain:example.com entry per line. It applies to that property, takes effect as the links are recrawled, and replaces any previous file, so keep a master copy.

Note: The disavow tool is a statement about links you cannot remove. Always attempt removal first for links you created, and document it, especially if you will need a reconsideration request.

Google says local results are based mainly on three things: relevance (how well a profile matches the search), distance (how far the business is from the searcher or the location in the query) and prominence (how well known the business is, both online and offline). You cannot change distance, so optimisation focuses on the other two.

Profile optimisation checklist:

• Primary category — the single most important choice. Pick the most specific category that describes the core business, then add relevant secondary categories.
• Accurate, complete information — the real business name (adding keywords to the name breaks Google's guidelines and risks suspension), address or service area, phone number, website, hours including holiday hours, and attributes.
• Services and products — list them with descriptions; they add relevance for specific queries.
• Photos — real photos of the premises, team and work, updated regularly.
• Reviews — ask every satisfied customer through a simple process, respond to all reviews including negative ones, and never buy or gate reviews. Review count, rating and recency all contribute to prominence and to click-through.
• Posts and Q&A — keep the profile active with offers, events and answers to common questions.

Supporting signals on and off the website:

• Consistent name, address and phone number across directories, aggregators and social profiles.
• A dedicated location page for each branch with unique content, embedded map, directions and LocalBusiness structured data, linked from the profile.
• Local links and mentions from chambers of commerce, local news, sponsorships and community sites.
• Organic strength of the website overall, which feeds prominence.

Measurement: the profile's performance data (calls, direction requests, website clicks, searches), UTM-tagged website links so profile traffic is identifiable in analytics, and rank tracking from grid points across the city, because local rankings vary block by block.

Note: For multi-location businesses, mention governance: one owner account, bulk management, a process for handling duplicate or suggested edits, and regular audits, because anyone can suggest changes to a public profile.

Search Console is Google's own view of your site, so each report answers a different diagnostic question. These are the ones I check most often:

Limitations to mention: Performance data is sampled and privacy-filtered (rare, anonymised queries are hidden, so query totals are lower than page totals); average position is an average across all impressions and is easily misread; and the interface caps exported rows, so large sites use the API, the BigQuery bulk export or Looker Studio.

Note: Verify a Domain property through DNS so every protocol and subdomain is covered, and add URL-prefix properties for key sections to get separate reports and higher export limits for each.

URL Inspection in Search Console is the most precise diagnostic tool for a single page. It shows what Google knows about that exact URL.

The default view is the indexed version, based on Google's last crawl. It tells you:

• Whether the URL is on Google, and if not, why (for example excluded by noindex, a redirect, a duplicate or a soft 404).
• How Google discovered it: referring pages and sitemaps.
• The last crawl date, whether it was crawled with the smartphone crawler, and whether crawling and indexing were allowed.
• User-declared canonical versus Google-selected canonical, which is the fastest way to confirm a canonical problem.
• Structured data and other enhancements detected.

The live test fetches the page now, using Googlebot, and shows:

• Whether the URL is currently available to Google (status code, robots.txt, noindex).
• The rendered HTML, a screenshot, page resources that failed to load, and JavaScript console messages, which makes it ideal for JavaScript SEO debugging.
• Structured data detected on the current version.

Key difference: the indexed result is history; the live test is the present. A live test that passes means the page can be indexed; it does not mean Google will index it, and it does not check duplication or quality. A page can pass the live test and still sit at “Crawled, currently not indexed”.

Practical workflow: after fixing a problem, run a live test to confirm the fix is visible to Googlebot, then use Request indexing for a handful of important URLs. Requests are subject to a daily quota, so for large numbers of URLs rely on updated sitemaps and internal links instead.

Note: Compare the rendered HTML with the page source. If key content, links or the canonical appear only in one of them, you have found a rendering problem that no amount of resubmitting will fix.

Server access logs record every request made to the site, including each request from search engine bots. A typical line includes the IP address, timestamp, requested URL, HTTP status code, bytes sent, referrer and user agent. Log file analysis filters these to search engine crawlers and shows what they actually did, rather than what a crawler tool predicts they could do.

Verify the bot first: anyone can fake a Googlebot user agent. Confirm genuine Googlebot with a reverse DNS lookup (the host should end in googlebot.com or google.com, followed by a matching forward lookup) or against the IP ranges Google publishes.

What logs reveal that a crawler cannot:

• Crawl distribution — which sections Googlebot spends its requests on. It is common to find most requests going to faceted filters, old parameters or calendar pages while key product pages are visited rarely.
• Crawl frequency per URL — how often important pages are revisited, and how long new pages take to be crawled for the first time.
• Status codes Googlebot really receives — including intermittent 5xx errors, timeouts or rate limiting that never appear in a one-off crawl.
• Orphan and legacy URLs — URLs Google still requests that have no internal links, such as old campaign pages or pre-migration URLs.
• Migration behaviour — whether Googlebot is following redirects and moving on to the new URLs.
• Rendering resources — whether JavaScript and CSS files are fetched successfully.

Tools: dedicated log analysers such as Screaming Frog Log File Analyser, or larger pipelines in BigQuery, Splunk or ELK for enterprise sites. Pull logs from every layer, because a CDN may answer many requests before they reach the origin server.

Note: Search Console's Crawl stats report is a useful aggregate, but it does not give you URL-level detail over long periods. For large e-commerce or publishing sites, logs are the only way to prove that crawl resources are being wasted and to measure whether a fix worked.

Faceted navigation lets users filter by colour, size, brand, price and so on. Each combination can create a new URL, so a catalogue of 5,000 products can produce millions of crawlable filter URLs. Most are near-duplicates with no search demand, and they consume crawling that should go to real products and categories.

Step 1: decide which facets deserve indexable pages. Some combinations match real searches, for example “men's running shoes under 3000” or “Nike running shoes”. Give these clean, static URLs, unique titles and some unique copy, link to them internally and include them in sitemaps.

Step 2: control everything else, choosing the right tool.

• Do not create crawlable links for low-value filters. Apply them with JavaScript or form controls that do not produce anchor links, or keep them in URL fragments. This is the cleanest fix because crawlers never discover the URLs.
• robots.txt disallow for parameter patterns, for example sort order, price sliders or session IDs. This saves crawling, but blocked URLs can still be indexed if linked, and signals on them are not consolidated.
• Canonical to the unfiltered category — consolidates signals, but Google still has to crawl the URLs to see it, so it does not save crawl budget.
• noindex — removes pages from the index but also requires crawling.

Step 3: keep URLs consistent. Fix the order of parameters, avoid duplicate paths to the same filter state, strip empty parameters, and return a 404 for filter combinations that produce no products.

How to confirm it worked: log files and Search Console Crawl stats should show a lower share of requests going to parameter URLs and more frequent crawling of products and categories.

Note: Google retired the URL Parameters tool in Search Console, so parameter handling now has to be solved on the site itself. Crawl budget really matters mainly for large sites; for a 500-page site, facets are more a duplicate-content issue than a crawl budget one.

• 404 Not Found — the page does not exist. Google drops it from the index after recrawling it a few times. 404s on pages that genuinely no longer exist are normal and do not harm the rest of the site.
• 410 Gone — the page was removed deliberately and permanently. Google treats it much like a 404; it may be processed slightly faster, but the difference is small in practice.
• Soft 404 — the server returns 200 OK but the page is effectively empty or says “not found”, such as an empty search result, an out-of-stock page with no content, or a removed page redirected to the homepage. Google flags these in the Page Indexing report and treats them as errors. They waste crawling and confuse reporting.

Deciding what to do with a removed page:

1. Is there a close replacement? If a newer model, merged article or parent category meets the same need, 301 redirect to it. This preserves users and link value.
2. Does the page have backlinks or traffic, but no exact replacement? Redirect to the most relevant category or hub, not the homepage.
3. No value and no equivalent? Return a 404 or 410 with a helpful error page that offers search and navigation.

Special cases:

• Temporarily out-of-stock products — keep the page live with a 200, show availability clearly, suggest alternatives and update the structured data. Do not remove or redirect it.
• Permanently discontinued products with demand — keep an informational page pointing to successors, or redirect.
• Server errors (5xx) — persistent 5xx responses make Google slow its crawling and eventually drop URLs. For planned maintenance, return a 503 with a Retry-After header rather than a 200 maintenance page.

Note: Watch robots.txt during outages. If robots.txt itself returns a server error, Google may pause crawling of the whole site until it can fetch it again, which turns a small outage into a crawl problem.

Pagination splits a long list, such as a product category or an article archive, across several URLs. The goal is for Google to discover every item in the list while keeping the category's main page as the one that ranks.

Current best practices:

• Give every page a unique, crawlable URL, such as /laptops/?page=2 or /laptops/page/2/, and link between pages with real anchor links (next, previous and page numbers).
• Use self-referencing canonicals on each page. Do not canonicalise page 2 and later pages to page 1; they contain different items, so Google may ignore the canonical, and products that appear only on deeper pages lose a discovery path.
• Do not noindex paginated pages by default if they are how products get discovered; over time, noindexed pages are crawled less and their links carry less weight.
• Avoid duplicating the page 1 copy on deeper pages; category introductions and FAQs can stay on page 1 only. Adding the page number to the title is a small but useful touch.
• Keep the first page strong — it should be the canonical target for category queries and receive most internal links.
• A “view all” page can work if it loads quickly; in that case, paginated pages can canonicalise to it.

rel=next and rel=prev: Google announced in 2019 that it no longer uses these link annotations as an indexing signal. They do no harm and other search engines or accessibility tools may use them, but they are not a solution on their own.

Infinite scroll and load-more buttons: Googlebot does not scroll or click, so items loaded only on interaction may never be discovered. Build infinite scroll on top of paginated URLs: each batch corresponds to a real page URL, the address bar updates with the History API as the user scrolls, and plain paginated links exist in the HTML for crawlers.

Note: Reducing pagination depth often helps more than any tag. More items per page, subcategories and filters that create useful landing pages all shorten the path to deep products.

Content pruning is the periodic review of a site's existing content to improve, consolidate or retire pages that no longer serve users or the business. Large sites accumulate outdated posts, overlapping articles and thin pages that dilute quality signals and waste crawl and editorial attention.

Step 1: build an inventory of every indexable URL with organic clicks and impressions (Search Console), conversions and engagement (analytics), referring domains (a backlink tool), word count, publish date and last update.

Step 2: classify each page with a decision framework:

Step 3: execute in batches and annotate the dates, so you can measure the effect on traffic to the remaining pages and on the site as a whole.

Cautions:

• Low organic traffic is not a reason to delete on its own. A page may exist for customers, sales, legal reasons or other channels.
• Seasonal content may look dead for ten months of the year.
• Look at the whole cluster; removing a supporting article can weaken internal links to the pillar page.

Note: Frame pruning as quality improvement, not deletion for its own sake. The strongest results usually come from merging and updating, while outright deletion is the smallest share of the work.

Mobile-first indexing means Google predominantly uses the mobile version of a page, crawled with the Googlebot smartphone user agent, for indexing and ranking. If something exists only on the desktop version, Google may effectively not see it. Google has moved essentially all sites to mobile-first indexing, so this is simply how Google indexes today.

Site configurations:

• Responsive design (same URL and HTML, different CSS) — Google's recommended approach and the least risky, because the content is identical by default.
• Dynamic serving (same URL, different HTML by user agent) — needs a Vary: User-Agent header and careful parity checks.
• Separate mobile URLs (such as m.example.com) — the riskiest: they need rel alternate and canonical annotations between versions, and the two versions often drift apart.

Parity checklist between mobile and desktop:

• Primary content — the same text, not a trimmed mobile version. Content inside tabs or accordions on mobile is fine, as long as it is in the HTML.
• Internal links — simplified mobile menus often drop category links, reducing crawl paths and link equity.
• Metadata — the same titles, meta descriptions, robots directives and canonicals.
• Structured data — present on the mobile version, with matching URLs.
• Images and video — the same assets with alt text, in crawlable formats, not blocked or lazy-loaded behind user interaction.
• hreflang — on separate mobile URLs, pointing to mobile equivalents.
• Performance and usability — readable text, tap targets, no intrusive interstitials.

How to check: crawl the site with a smartphone user agent and compare it with a desktop crawl for word count, links and metadata, and use URL Inspection to confirm the page was crawled by Googlebot smartphone and view its rendered output.

Note: Mobile-first is about which version is indexed, not about mobile-friendliness scores. A fast, attractive mobile site can still lose rankings if its menus and content were trimmed compared with desktop.

• Zero-click search — a search that ends without a click to any website, because the answer appears on the results page itself: featured snippets, knowledge panels, calculators, weather, local packs and so on.
• AI Overviews — AI-generated summaries that Google shows for some queries, with links to the sources used; AI Mode works on a similar principle. These features answer more of the question on the results page, which can reduce clicks for informational queries even when rankings hold steady.

What Google has said about eligibility: there is no special markup or separate optimisation for appearing in AI features. A page must be indexed and eligible to show a snippet in normal search, and the usual quality signals apply. Snippet controls such as nosnippet, max-snippet and data-nosnippet also limit how content can be used in these features. Clicks and impressions from AI features are included in Search Console's web search data rather than reported separately.

How to adapt the strategy:

• Reassess keyword value — simple definitional queries may lose most of their clicks; queries needing comparison, first-hand experience, tools, local detail or a transaction keep sending traffic.
• Create content that is worth citing — original data, expert views, clear direct answers with depth underneath, and first-hand examples that a summary cannot replace.
• Structure pages clearly — descriptive headings, concise definitions near the top, tables and lists. This helps users and retrieval systems alike.
• Build the brand — mentions, reviews and branded search. If users are shown your name, they may search for you directly later.
• Diversify — YouTube, communities, newsletters and other channels that are less exposed to answers on the results page.

How to measure it: track impressions and CTR separately from clicks, watch for queries where impressions rise while CTR falls, follow branded search volume and conversions from organic, and judge success by business outcomes rather than traffic alone.

Note: Keep claims about AI search durable in an interview. The features change quickly, so emphasise principles (quality, clarity, originality and measurement of real outcomes) rather than tactics tied to one version of the interface.

A technical audit checks whether search engines can crawl, render, index and understand the site, and whether performance and structure are holding it back. Work from the foundations upwards.

1. Gather data — a full crawl with a tool such as Screaming Frog or Sitebulb (with JavaScript rendering on for JavaScript-heavy sites), Search Console exports, analytics landing-page data and, for large sites, server logs.
2. Crawlability — robots.txt rules, blocked resources, server errors, redirect chains and loops, and crawl traps such as faceted filters or calendars.
3. Indexability — the Page Indexing report, noindex usage, canonical conflicts, duplicate and thin pages, and soft 404s. Compare indexed counts with the number of pages you expect.
4. Rendering — compare raw and rendered HTML for key templates, and check content and links that depend on JavaScript.
5. Architecture and internal links — click depth, orphan pages, broken internal links, links to redirected URLs and navigation coverage.
6. On-page elements at scale — missing or duplicate titles, H1s and meta descriptions, and very thin pages, grouped by template.
7. Performance — Core Web Vitals field data by template.
8. Structured data, hreflang and sitemaps — errors, reciprocity, and whether sitemaps contain only canonical 200 URLs.
9. Security and mobile — HTTPS, mixed content and mobile parity.

How to prioritise: score every issue on impact (how many pages, and how valuable they are in traffic and revenue), effort (engineering time and risk) and confidence that fixing it will help. Blockers that affect important templates, such as a noindex on category pages or products missing from the rendered HTML, go first regardless of effort. Then come high-impact, low-effort fixes. Cosmetic issues on low-value pages go to the backlog.

Deliverable: a short executive summary with the top five issues and their estimated impact, then a ticket-ready list for each issue with the affected URLs, the fix, an owner and acceptance criteria.

Note: An audit is only worth what gets implemented. Group issues by template and team, explain the “why” in business terms, and re-crawl after each release to confirm the fixes and catch regressions.