Search Marketing FAQ

Yes, but with caveats. AggregateRating on LocalBusiness for third-party-sourced reviews (Yelp count + average) is still allowed. Self-serving aggregate rating from on-site reviews you control no longer shows star snippets in 2026. Use review platform widgets (Trustpilot, Google reviews) which generate their own validated schema. Avoid mocking up unverifiable ratings.

in Review Schema & Monitoring

Limited entity types. Product pages with Product schema + review. Book, Movie, Course, Recipe, Event pages. Software apps. Restaurant menu items (rare). LocalBusiness pages are no longer eligible for self-serving reviews. Check Google's current rich result eligibility list (developers.google.com/search/docs/appearance/structured-data). The list narrows over time.

in Review Schema & Monitoring

Five reasons. Rich result type deprecated for your entity. Missing recommended properties (not just required). Page quality below Google's rich result threshold. Manual action against the site or page. Recent rollout - Google can take days to weeks to surface rich results. Validating ≠ eligibility. Use GSC Enhancement reports for definitive rich result tracking.

in Review Schema & Monitoring

Match schema to actual page content. Don't add Recipe schema to a non-recipe page. Don't add Review schema where reviews don't exist. Don't add 5+ schema types to compete for rich results. Less but accurate beats more but spammy. Manual actions for structured data spam exist; recovery is slow. When in doubt, leave the schema off.

in Review Schema & Monitoring

Three layers. Google Search Console Enhancement reports per schema type (impressions, clicks, errors). Manual Rich Results Test on key URLs monthly. SDTT or ScreamingFrog batch validation across the site quarterly. Track rich result impressions over time as a leading indicator. Set up GSC alerts for spike in structured data errors. Schema is not set-and-forget.

in Review Schema & Monitoring

Two complementary tools. Schema.org Validator (validator.schema.org) - generic syntax + semantic checks against full Schema.org spec. Google Rich Results Test (search.google.com/test/rich-results) - Google-specific rich result eligibility check. Run both. Schema can validate against Schema.org but fail Rich Results Test (missing Google-specific recommended properties). Both validations should pass before deploying.

in Review Schema & Monitoring

Three metrics. LCP (Largest Contentful Paint) - loading performance, under 2.5s good. INP (Interaction to Next Paint) - interactivity, under 200ms good. CLS (Cumulative Layout Shift) - visual stability, under 0.1 good. INP replaced FID (First Input Delay) in March 2024. All three measured at 75th percentile across page views in 28-day rolling window.

in Core Web Vitals Metrics

LCP measures when the largest content element above the fold finishes rendering. Usually a hero image, video poster, or large text block. Threshold: under 2.5s = good, 2.5-4s = needs improvement, over 4s = poor. LCP is the strongest correlation with perceived page load speed. Optimizing LCP usually means optimizing the hero image and TTFB.

in Core Web Vitals Metrics

INP measures the responsiveness of all user interactions on the page - clicks, taps, key presses. Reports the slowest interaction (or 98th percentile of interactions on busy pages). Threshold: under 200ms = good, 200-500ms = needs improvement, over 500ms = poor. INP replaced FID in March 2024. Driven by main thread work, especially JavaScript execution.

in Core Web Vitals Metrics

CLS measures the sum of unexpected layout shifts during the page lifetime. Lower is better. Threshold: under 0.1 = good, 0.1-0.25 = needs improvement, over 0.25 = poor. Causes: images without explicit dimensions, ads injected mid-load, web fonts swapping. Fixed by reserving space for dynamic content with CSS sizing or aspect-ratio.

in Core Web Vitals Metrics

Time to First Byte. Measures how long from request start until the first byte of response arrives. Indicator of server response time + network latency. Threshold: under 800ms = good, 800-1800ms = needs improvement. Not part of Core Web Vitals but a strong leading indicator of LCP and FCP. Improved by CDN, server-side caching, faster hosting.

in Core Web Vitals Metrics

First Contentful Paint. The time until the first text or image renders. Threshold: under 1.8s = good, 1.8-3s = needs improvement. Not part of Core Web Vitals but tracked in Lighthouse. FCP is influenced by render-blocking CSS, server response time (TTFB), and resource priority. Optimize critical CSS inlining and reduce render-blocking JS to improve FCP.

in Core Web Vitals Metrics

Six tactics. Inline critical CSS (reduces render-blocking CSS). Defer non-critical JavaScript with defer or async attributes. Preconnect to required origins (fonts, analytics). Reduce TTFB via CDN and server-side caching. Avoid synchronous third-party scripts in the head. Minify CSS and JS. Use font-display: swap to prevent invisible text. FCP improvements compound into LCP gains.

in Core Web Vitals Metrics

Lab data: simulated test under controlled conditions (Lighthouse). Field data: real user measurements from actual visitors (Chrome User Experience Report aka CrUX). Google's Core Web Vitals assessment uses field data, not lab. Lab is useful for diagnosis (why is it slow?); field is what counts for ranking (what do real users experience?). Always check both.

in Core Web Vitals Metrics

Six reasons. Lab data simulates one device under one network condition; field data aggregates across all users. Lighthouse runs in a clean browser; real users have extensions, multiple tabs, slower devices. Lab uses cold cache; many real users have warm cache. Lighthouse runs Chrome on desktop; mobile users use various Android/iOS browsers. Trust field data for ranking impact.

in Core Web Vitals Metrics

web.dev itself - Google's official documentation site. web.dev/learn/performance is the structured course. PageSpeed Insights (pagespeed.web.dev) for live URL testing with both lab and field data. CrUX Dashboard (g.co/chromeuxdash) for site-wide field data. Chrome DevTools Performance tab for deep diagnostics. Start with PSI to identify the problem, web.dev to learn fixes.

in Core Web Vitals Metrics

Per-URL when sufficient data exists (typically 10,000+ visits in 28 days). Below that threshold, Google rolls up to origin-level. Different URLs on the same domain can have different ranking impacts. High-traffic pages get evaluated individually; long-tail pages share the origin-level assessment. Optimize highest-traffic pages first for maximum CWV impact.

in Core Web Vitals Metrics

Google reports CWV at the 75th percentile across all page visits in a 28-day rolling window. To pass, 75% of visits must be in the 'good' threshold. The remaining 25% can be worse. This rewards consistency - one outlier visit doesn't tank the assessment, but a slow tail (lots of slow visits) does. Optimize for the long tail, not the median.

in Core Web Vitals Metrics

Six causes. Unoptimized hero image (huge file, wrong format, not preloaded). Render-blocking CSS in the head. Slow server response (high TTFB). LCP element is in a lazy-loaded section. Web fonts loading the LCP text. Third-party scripts blocking the main thread. Identify the LCP element in Chrome DevTools; optimize the specific bottleneck.

in Core Web Vitals Metrics

Five causes. Heavy JavaScript execution on the main thread (over 50ms tasks). Synchronous third-party scripts (chat widgets, analytics). Inefficient event handlers that do too much work. Large hydration cost on JavaScript frameworks. Forced synchronous layouts from JS reading layout properties mid-paint. Profile with Performance tab; long tasks are the smoking gun.

in Core Web Vitals Metrics

Five causes. Images without explicit width/height attributes (layout reserves no space). Ads injected mid-load with variable size. Web fonts swapping (FOUT - flash of unstyled text). Dynamically injected banners (cookie consent, promotions). Animations triggered by JavaScript that shift content. Fix: reserve space with CSS sizing, use font-display: optional, animate transform not layout properties.

in Core Web Vitals Metrics

The practice of reducing page load time and improving runtime responsiveness. Encompasses asset optimization (images, CSS, JS), network strategy (CDN, caching, compression), code efficiency (bundle size, render path), and measurement (Core Web Vitals, Lighthouse, RUM). Trade-off: developer convenience vs end-user speed. Performance is a ranking factor and conversion factor.

in Performance Optimization

Five. LCP (loading speed). INP (interactivity). CLS (visual stability). TTFB (server response). FCP (first paint). The first three are Core Web Vitals (ranking factor); the last two are diagnostic indicators. Track all five in field data (CrUX, real user monitoring). Use lab data (Lighthouse) for individual URL diagnosis.

in Performance Optimization

Five-step process. Run PageSpeed Insights on top-traffic URLs. Open Chrome DevTools Performance tab to record a slow page load. Identify long tasks (over 50ms) on the main thread. Check the Coverage tab for unused CSS/JS. Review the Network tab for slow requests and render-blocking resources. Prioritize fixes by impact on LCP and INP.

in Performance Optimization