The Field-vs-Lab Audit: Finding Which Template Is Actually 'Poor'
Objective: Use Search Console's real-user field data, grouped by URL template, to find which page type is dragging RateGain's Core Web Vitals down, then use a crawl to spot the likely CLS-causing pattern on that template.
RateGain Travel Technologies markets its hotel-pricing-intelligence platform through a content-heavy marketing site plus a gated demo-request flow. The team optimized the homepage's Core Web Vitals last quarter and assumed the whole site improved. You're checking whether that's actually true.
Two passes: read the Search Console URL-groups breakdown to find which template is still 'Poor', then crawl that template to spot the most likely CLS culprit.
Is the performance problem caused by individual pages, or by a shared page template?
Before you start
What you'll need
- —Basic understanding of what Core Web Vitals measures
- —Access to Google Search Console for the property being audited
- Largest Contentful Paint (LCP)
- measures how quickly the largest visible content element loads.
- Cumulative Layout Shift (CLS)
- measures unexpected movement of visible content while a page loads.
Free path (everything below is enough to finish)
Free, and the only source of real-user field data grouped by page template.
Free tier crawls up to 500 URLs, plenty for a 38-URL template audit.
Paid upgrades (optional, faster/deeper)
Both checks are complete on free tools. Ahrefs only helps track whether organic performance moves after the fix ships.
Both diagnostic checks are complete on free tools. Ahrefs only helps track whether organic performance moves after the fix ships.
The process
2 steps
Step 01 of 02
The lesson's warning about the Core Web Vitals mistake: teams optimize the homepage, see a green checkmark, and stop, while the templates driving most of the traffic stay in 'Poor'. Search Console groups URLs by template specifically to catch this.
The homepage passes all three Core Web Vitals. Does that mean the site passes? Check the URL-groups breakdown to find out.
Procedure
- Open Core Web Vitals > Mobile report in Search Console
- Click into the 'Poor' status row to see the affected URL groups
- Sort URL groups by number of affected URLs, not by which page feels most important
- Note the LCP value and page count for the largest 'Poor' group
Core Web Vitals, Mobile, URL Groups ------------------------------------------ Homepage template: GOOD, LCP 2.1s (1 URL) Hotel case-study template: POOR, LCP 4.6s (38 URLs, 61% of site traffic) Pricing/demo template: NEEDS IMPROVEMENT, LCP 3.0s (4 URLs) Blog template: GOOD, LCP 2.3s (52 URLs)
Healthy
Every high-traffic template, not just the homepage, sits in the Good bucket in the URL-groups breakdown.
Unhealthy
The hotel case-study template, 61% of site traffic, sits at 4.6 seconds LCP in the Poor bucket, while the homepage the team already optimized carries just one URL's worth of traffic.
What this means
The homepage fix was real but nearly irrelevant to overall site health: it's one URL. The case-study template touches 38 URLs and the majority of traffic, exactly the 'fix the homepage, declare victory' trap the lesson warns about.
So what do I do about it?
| Symptom | Action | Effort |
|---|---|---|
| 61% of site traffic sits on a template stuck at 4.6s LCP | Prioritize the case-study template for the next optimization sprint, not another homepage pass | half day |
Step 02 of 02
The lesson lists images and videos without defined width/height as the most common CLS cause, alongside ads and late-injected content.
Now that the case-study template is the known problem, crawl it for the most common technical cause of layout shift: images missing explicit dimensions.
Procedure
- Crawl the 38 case-study template URLs in Screaming Frog (well within the 500-URL free limit)
- Open the Images tab and check for images missing width/height attributes
- Cross-reference count against the number of hero images and embedded logo grids on the template
- Note whether the pattern is consistent across all 38 URLs (a template-level bug) or scattered (a content-entry mistake)
Screaming Frog, Images Tab, Case-Study Template Crawl ------------------------------------------ Total images crawled: 214 Missing width/height attributes: 187 (87%) Pattern: the hero banner and the 'client logo' grid component both render without dimensions across all 38 URLs, consistent template bug, not a one-off content mistake.
Healthy
Every image on the template has explicit width/height attributes, so the browser reserves the correct space before the image loads.
Unhealthy
87% of images across all 38 case-study URLs lack width/height, and the pattern repeats identically on every URL, a component-level bug, not isolated content errors.
What this means
Because this shows up identically on every one of the 38 URLs, it's a shared component (the hero banner and logo grid), not something 38 separate content editors each got wrong. One template fix resolves it everywhere at once.
So what do I do about it?
| Symptom | Action | Effort |
|---|---|---|
| 87% of images on the case-study template lack width/height attributes | Add explicit width/height to the hero banner and logo-grid components in the template code, not on individual pages | dev ticket |
Analyze your findings
What to look for
- Severity
- How poor is the performance for this template?
- Scale
- How many URLs share the same template?
- Business importance
- How much traffic or business value does the template represent?
- Repeatability
- Does the same problem appear across many pages using the same template, or is it isolated to one or two?
Make the call
Based on the evidence gathered so far, what should the SEO team recommend?
Recommendation · Priority: High
“The hotel case-study template should be prioritized for Core Web Vitals optimization. The template carries a Poor LCP result (4.6s) and affects 38 URLs representing 61% of site traffic. A crawl confirms a repeated image-implementation issue, missing width/height attributes on the hero banner and client logo grid, consistent across every affected URL. Development should correct the shared components rather than modifying individual pages.”
Common mistakes
What trips people up
Checking only the homepage — a passing homepage does not prove that other page templates perform well.
Choosing the worst score automatically — a severe problem on one low-traffic page can matter less than a moderate problem spread across hundreds of high-traffic pages.
Assuming the first technical issue found is the root cause — confirm the pattern repeats across the affected URLs before declaring a root cause.
Treating every affected URL as a separate problem — if the same issue appears across a shared template, fix the template, not each page one by one.
Final deliverable
A prioritization memo naming the case-study template as the real Core Web Vitals problem (not the homepage), with the specific component-level CLS cause and fix.
See a reference example
The same two-step check on Wise's currency-guide template (illustrative) found the reverse pattern: homepage still Poor at 3.8s LCP, while every content template already passed. The fix there was a hero video autoplay on the homepage alone, a one-page problem instead of a template-wide one.
Success criteria
You're done when you can:
- Used the URL-groups breakdown, not just the homepage score, to find the real problem template
- Weighted the finding by number of affected URLs / traffic share, not by which page 'feels' important
- Found a specific, template-level CLS cause via crawl, not a guess
- Distinguished a template-wide bug (87% consistent) from scattered content mistakes
Key takeaway
A professional technical SEO audit does more than identify a poor score. It answers where the problem is, how widespread it is, what's causing it, and what the business should do next. The goal isn't to find errors, it's to turn technical evidence into a prioritized action that improves the site at scale.