Questions d'entretien : SEO Specialist

Server logs show which URLs search bots actually requested, rather than which URLs a crawler could theoretically reach.

• Each request provides direct evidence of crawl frequency, status codes, and resources fetched by a specific user agent.
• Logs can expose repeated bot visits to parameter URLs that never appear in a configured site crawl.
• They do not show whether Google indexed or ranked a fetched page, so I pair them with Search Console and crawl data.

I need enough fields to identify the requester, requested resource, response, and timing.

• The timestamp, host, path, query string, and HTTP method reconstruct exactly what was requested and when.
• Status code, response bytes, and request duration reveal errors, redirects, unusually empty responses, and slow delivery.
• User agent and client IP support bot verification, while the referrer can add context but is often absent for crawlers.
• I also confirm the logging layer because CDN, load balancer, and origin logs may record different parts of the request path.

A user-agent string is easy to spoof, so I verify the source IP through Google's documented DNS or published IP ranges.

• For DNS verification, a reverse lookup should resolve to a Google-owned hostname and a forward lookup must return the original IP.
• Google's published crawler IP lists provide another authoritative check that can be automated against log addresses.
• I classify unverified requests separately instead of letting spoofed traffic distort crawl-frequency conclusions.

I compare bot requests by URL group and time period, then treat the pattern as crawling evidence rather than indexing evidence.

• Daily requests by directory, template, status, and parameter reveal where crawl activity is concentrated or wasted.
• Repeated hits on old redirects and rare visits to important deep pages can expose weak cleanup or discovery paths.
• Retention gaps, caching layers, sampling, and unlogged subdomains can make the dataset incomplete.
• A change in request volume may reflect demand, server health, or Google's scheduling, so logs alone do not prove a ranking cause.

For large sites, crawl budget is constrained by what Google can fetch safely and what it considers worth fetching.

• Crawl capacity responds to server speed, errors, and limits so Googlebot does not overload the host.
• Crawl demand reflects factors such as URL popularity, freshness, perceived value, and the need to revisit changed pages.
• Improving capacity does not force more crawling when demand is low, and high demand cannot overcome a consistently failing server.

Crawl budget matters mainly when a site exposes far more URLs than search engines can efficiently revisit.

• Large ecommerce, marketplace, publisher, and user-generated sites can create millions of changing or duplicate URLs.
• A small stable site with clean links rarely benefits from trying to optimize a supposed daily crawl allowance.
• I look for delayed crawling of valuable pages alongside heavy bot activity on low-value spaces before calling it a budget problem.

Facets can generate a near-infinite crawl space when every filter order and combination creates a reachable URL.

• Color, size, brand, sort, and price parameters can multiply one category into thousands of near-duplicate pages.
• Crawlable links to every combination let bots spend requests on thin states while important products wait for revisits.
• I keep valuable search-demand facets indexable and linked, while controlling valueless combinations through link design, canonicals, robots rules, or noindex according to whether crawling or indexing is the problem.
• Canonical tags alone may consolidate duplicates but do not prevent bots from requesting those URLs.

A clean sitemap helps discovery and prioritization, but it does not close an uncontrolled crawl space.

• It should list preferred canonical URLs with accurate lastmod values only when content changed meaningfully.
• Internal links can still lead Googlebot into millions of parameters even if those URLs are absent from the sitemap.
• Server logs show whether valuable sitemap URLs gain visits while low-value patterns continue consuming requests.

Google must fetch the URL, process its resources, render the page when needed, and then evaluate the rendered result for indexing.

• The initial HTML can provide immediate content and links before JavaScript execution.
• Rendering requires accessible scripts, APIs, and enough resources, and it may happen after the first fetch.
• The rendered DOM, directives, canonical, and content can affect what Google ultimately understands and selects for indexing.
• Successful rendering still does not guarantee indexing because duplication, quality, and canonical selection remain separate decisions.

Server-rendered or static HTML reduces the number of dependencies before critical content and links become available.

• A client-rendered shell may require JavaScript bundles and API calls before a crawler can see the main page content.
• SSR sends useful HTML per request, while static generation can serve prebuilt HTML quickly for pages that do not need request-time data.
• Hydration and later client updates can still remove or contradict server output, so I inspect both the response and rendered DOM.
• CSR can be acceptable for private app screens, but public search landing pages gain resilience from meaningful initial HTML.

A reliable crawlable link is an anchor element with a real destination in its href attribute.

• An <a href="/products/blue-shoes"> link gives crawlers and users a standard navigation target.
• Click handlers on div elements, buttons, or anchors without href may not enter the crawler's link graph.
• Hash fragments that only change client state usually do not represent separate discoverable documents.
• The destination should resolve without requiring a prior click sequence, session state, or form submission.

Lazy loading becomes an SEO risk when content appears only after a user action that a crawler may never perform.

• Images near the viewport can use native loading="lazy", but the LCP image should normally load eagerly and be discoverable in HTML.
• Infinite-scroll items need crawlable paginated URLs or links rather than depending only on scrolling and API calls.
• Tabs and accordions may be visually collapsed, yet their important content should exist in the rendered DOM without a click.
• I test rendered HTML and resource requests, not just what appears after manually interacting in my browser.

Rendering differences usually come from blocked resources, failed data requests, environment assumptions, or code errors.

• A robots rule that blocks a critical script or API can leave Google with an empty template.
• Authentication, cookies, geolocation, or unsupported browser checks can make crawler requests receive different data.
• Timeouts, rate limits, and uncaught JavaScript errors can prevent late content from entering the rendered DOM.
• I compare raw HTML, browser rendering, URL Inspection output, and server responses to locate the dependency that diverges.

No, I prefer server rendering, static generation, or progressive enhancement over maintaining separate crawler output.

• Dynamic rendering creates two rendering paths that can drift and increase operational and cloaking risk.
• Google describes it as a workaround rather than a recommended long-term solution.
• A shared rendering path gives users and crawlers the same content and makes failures easier to test.

Reciprocal hreflang confirms that each localized page recognizes the others as members of the same language set.

• If the English page points to French, the French page should point back to English.
• Every member should also include a self-reference with its own language or language-region code.
• Missing return links can cause search engines to ignore incomplete relationships rather than trust a one-sided declaration.
• All referenced URLs must be crawlable canonical pages that return successful responses.

x-default identifies the fallback URL for users whose language or region has no more specific match.

• It often points to a language selector, global homepage, or default international version.
• It does not replace explicit en, en-GB, or other annotations for audiences the site directly serves.
• The x-default URL joins the same reciprocal hreflang set and should reference the alternatives back.

Each genuine localized page should normally canonicalize to itself while hreflang connects it to equivalent locales.

• Canonicalizing French to English asks Google to consolidate the French URL while hreflang asks it to serve that URL, which sends conflicting signals.
• Every hreflang target should be the canonical URL for that locale, not a redirect or parameter duplicate.
• Same-language regional duplicates may need more nuanced canonical choices, but removing a locale from indexing also weakens its ability to serve through hreflang.

I use stable, crawlable locale URLs and let users switch versions instead of forcing a destination from IP or browser language alone.

• Country domains, subdomains, and subdirectories can all work when each locale has a distinct consistent URL.
• An IP-based redirect can block users and crawlers from reaching alternative versions or sharing a chosen URL.
• A visible language selector and a suggested locale preserve access while allowing the user's choice to persist.
• Locale URLs need matching content, canonicals, hreflang, sitemaps, and internal links rather than language detection only.

Each useful pagination URL should be reachable through normal links and represent its own place in the sequence.

• Page 2 and later should have crawlable <a href> links rather than requiring a load-more click only.
• Each page normally uses a self-referencing canonical because its item set differs from page 1.
• Titles or headings can clarify the sequence, while the core category description does not need to be duplicated heavily on every page.
• Products should remain reachable through stable pagination even when infinite scroll improves the user interface.

Google no longer uses rel next and rel prev as an indexing signal, so pagination must work through ordinary crawlable links.

• Existing annotations are not a substitute for links between adjacent or relevant sequence pages.
• Other consumers may still use the markup, so removal is optional rather than an SEO emergency.
• Canonicals should reflect duplicate content rules, not point every paginated URL to page 1 merely because it belongs to a sequence.