Organic Traffic Drop Diagnosis
Diagnose an organic traffic drop by separating clicks, impressions, CTR, rankings, indexing, technical changes, migrations, tracking, seasonality, SERP changes, and competition.
Read the guide →Core Web Vitals
Core Web Vitals Audit: Diagnose LCP, INP and CLS Problems
A Core Web Vitals audit starts with field data, then uses lab tests to reproduce and diagnose poor LCP, INP, and CLS. Separate template-level patterns from page-level outliers, identify root causes in server response, assets, scripts, and layout, then validate improvements over the field-data window.
Quick overview
Summary
- A Core Web Vitals audit starts with field data, then uses lab tests to reproduce and diagnose poor LCP, INP, and CLS.
- Separate template-level patterns from page-level outliers, identify root causes in server response, assets, scripts, and layout, then validate improvements over the field-data window.
- Core Web Vitals auditing is not the same as chasing a PageSpeed score.
Core Web Vitals auditing is not the same as chasing a PageSpeed score. A page can look strong in one lab run while real users still experience slow loading, delayed interaction, or unstable layout.
The audit should begin with field data, identify which metric and page groups are failing, and then use lab tools to reproduce and diagnose the underlying cause.
What Is a Core Web Vitals Audit?
A Core Web Vitals audit evaluates real-user and lab performance for Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). The objective is to explain why a page group fails, not simply report a score. For a focused next step, review fix Technical SEO issues.
Start With Field Data, Not Only Lighthouse
Use Chrome UX Report data where available, PageSpeed Insights field data, and Search Console Core Web Vitals groups. Field data reflects real users and is evaluated over a rolling window. Then use Lighthouse or other lab diagnostics to reproduce problems under controlled conditions. For a focused next step, review organic traffic drop diagnosis.
Diagnose LCP: Loading and Largest Content
Identify the LCP element and determine what delays it. Common causes include slow TTFB, render-blocking CSS, late-discovered images, oversized hero media, font behavior, and client-side rendering. Fix the bottleneck affecting the actual LCP element rather than optimizing unrelated assets.
Diagnose INP: Responsiveness and Main-Thread Work
INP reflects interaction responsiveness. Investigate long main-thread tasks, heavy JavaScript, expensive event handlers, third-party scripts, hydration, and UI work triggered after user input. A page can load quickly but still feel slow when clicks or taps take too long to produce a visual response.
Diagnose CLS: Layout Stability
CLS problems often come from images without reserved dimensions, ads, embeds, banners, fonts, dynamically inserted content, and late-loading UI. Observe which elements move and why, then reserve space or change loading behavior so visible content remains stable.
Separate Template-Level From Page-Level Problems
Group URLs by template. If all product pages fail INP while articles pass, the root cause is probably template or component specific. If only one page fails, inspect its unique assets or embeds rather than changing the entire site. For a focused next step, review WordPress Technical SEO.
Check Server Response, Images, Fonts, CSS and JavaScript
Review TTFB, caching, CDN behavior, image formats and dimensions, font loading, render-blocking CSS, JavaScript payloads, main-thread work, and third-party scripts. Prioritize the resource that actually contributes to the failing metric.
Use PageSpeed Insights, CrUX and Search Console Together
Each tool has a different role. Search Console shows grouped field issues, CrUX provides real-user measurements, and PageSpeed Insights combines field and lab diagnostics. Do not treat a single Lighthouse score as the final verdict.
Prioritize Fixes by Affected Page Group
Fix issues affecting high-value templates and large URL groups first. A sitewide LCP problem on product pages usually matters more than a one-off low-traffic article. For implementation beyond diagnosis, use Core Web Vitals optimization.
Validate Improvements Over the Field-Data Window
Lab improvements can be checked immediately, but field data takes time to reflect new user experiences. Monitor the affected groups and compare real-user metrics after enough fresh data accumulates. If the performance issue followed a launch, pair the audit with a post-migration SEO audit.
Final Thoughts
A useful Core Web Vitals audit identifies which metric fails, which templates are affected, and which resource or component causes the failure. Start with field data, use lab tests for diagnosis, and validate the improvement in real-user data.
The supplied query maps define all 10 English/Turkish pairs as true equivalents with the same core diagnostic intent in their respective languages. The Turkish article blueprint is now part of the same implementation program, so the preferred release model is to publish each EN/TR pair together and activate reciprocal hreflang immediately.
- For every pair that is live in the same release: self-canonical each URL; add reciprocal `hreflang="en"` and `hreflang="tr"` on BOTH pages; retain the English URL as `x-default` if that remains the site-wide convention.
- Language switchers on each of the 10 new English pages should point directly to the true Turkish equivalent, not to the generic Turkish blog hub.
- The /blog/ hub already has a true Turkish equivalent at /tr/blog/; preserve reciprocal en/tr plus English x-default during both hub redesigns.
- If deployment is deliberately split and one counterpart is not live yet, do not publish a dead hreflang target. Add the pair only when both canonical URLs are live.
- Do not infer language equivalence between merely related articles. Hreflang is only for true translated/equivalent pairs.
| English canonical | Turkish equivalent |
|---|---|
| /blog/website-crawlability-audit/ | /tr/blog/web-sitesi-tarama-denetimi/ |
| /blog/website-indexability-audit/ | /tr/blog/web-sitesi-indekslenebilirlik-denetimi/ |
| /blog/internal-linking-audit/ | /tr/blog/ic-baglanti-denetimi/ |
| /blog/redirect-audit/ | /tr/blog/yonlendirme-denetimi/ |
| /blog/organic-traffic-drop-diagnosis/ | /tr/blog/organik-trafik-dususu-analizi/ |
| /blog/post-migration-seo-audit/ | /tr/blog/site-tasima-sonrasi-seo-denetimi/ |
| /blog/url-is-unknown-to-google/ | /tr/blog/url-google-tarafindan-bilinmiyor/ |
| /blog/duplicate-without-user-selected-canonical/ | /tr/blog/canonical-olmadan-yinelenen-sayfa/ |
| /blog/schema-markup-audit/ | /tr/blog/schema-markup-denetimi/ |
| /blog/core-web-vitals-audit/ | /tr/blog/core-web-vitals-denetimi/ |
Files / routing
- Create each article as `/blog/<slug>/index.html` following the static V43 folder convention.
- Update `/blog/index.html` to the new hub structure.
- Add/update only the CSS/JS necessary for hub search/filter and reused article components. Prefer the current `/assets/css/styles-v41.css` and `/assets/js/main-v41.js` architecture instead of introducing unnecessary new bundles.
- Add the ten WebP assets to `/assets/images/` using the exact production filenames in Part D.
- Update sitemap.xml with the 10 new English canonical URLs. If the paired Turkish blueprint is deployed in the same build, include all 20 new canonical URLs. Preserve existing URLs and lastmod convention; do not remove unrelated entries.
- Do not add filter/search/category URLs to sitemap.xml, robots.txt, canonical logic or schema.
Analytics / consent
- Preserve the current GTM bootstrap and consent gating exactly as implemented in V43.
- Do not fire analytics before the existing consent state allows it.
- CTA links should use the site’s existing CTA/button classes and labels so current GTM click tracking remains compatible. Do not create a second analytics system for the new pages.
- Hub search/filter interaction tracking is optional and not required for launch. Do not delay implementation or add URL parameters solely for analytics.
Performance
- Convert supplied PNGs to WebP before production; do not serve the multi-megabyte source PNGs on the website.
- Use explicit image dimensions to avoid CLS.
- Lazy-load below-the-fold hub and related-card images. Keep the article hero image high priority.
- Hub filtering must be lightweight vanilla JS; no search library/framework is needed for 38 items.
- Do not duplicate large images into separate card copies unless performance testing demonstrates a real benefit.
Automated / file-level QA
- All 10 new article folders exist and all 10 production WebP files exist.
- All 10 new URLs are present exactly once in sitemap.xml.
- No old sitemap URL is accidentally removed.
- All 38 English article URLs are present as normal href links in the initial /blog/ HTML.
- No `?category=`, `/page/2/`, search-result or filter URLs are generated by the hub.
- No href points to an unpublished dedicated service URL unless that service page is part of the same release.
- No broken internal links among the 10 new pages, 30 inbound placements, related-card links and hub library.
- Exactly one H1 per new article and exactly one H1 on /blog/.
- Canonicals are absolute HTTPS and self-referencing.
- OG/Twitter images use the production WebP URLs and resolve successfully.
- FAQPage schema questions/answers match visible FAQ copy.
- Hub ItemList count and members match the actual 38-article library.
Rendered / browser QA
| Viewport / check | Acceptance |
|---|---|
| Desktop ≥1280px | Compact hero; search + six chips fit/wrap cleanly; 2 featured; 3 recent; 3×3 guide grid; readable 3-column text links; CTA band balanced. |
| Tablet ~768–1024px | Chips wrap or scroll without clipping; cards collapse appropriately; no horizontal overflow. |
| Mobile 320–430px | H1s wrap cleanly; search full width; chips usable by touch; cards stack; no cropped text/images; CTA buttons remain clear. |
| Contrast | Eyebrows, helper text, dates, metadata and inactive chips remain readable against cream/ivory backgrounds. |
| No-JS check | Full blog library remains visible; every article link is crawlable; search/filter enhancement may be unavailable but page is fully usable. |
| JS check | Search + chip filtering combine correctly; All resets topic; empty search restores; zero results message appears; URL does not mutate. |
| Image check | All article images render 1200×630 aspect ratio without distortion, overflow or layout shift. |
| Schema | Validate representative article and hub JSON-LD for syntax; check required graph IDs/references and no duplicate conflicting entities. |
| Consent/analytics | Cookie-consent behavior, GTM loading and existing lead/CTA instrumentation match V43 behavior. |
SEO acceptance checks
- Every new article owns its approved primary diagnostic intent and does not have headings/meta rewritten toward excluded queries.
- Hub hierarchy is a knowledge library, not a chronological wall of cards.
- No article is dependent on search/filter JS for discovery.
- Inbound links are contextual and natural; no full-mesh cross-linking among all 10 child pages.
- Commercial CTAs point to the next logical service without changing the informational page’s primary intent.
- Existing English pillar/child, Shopify, migration, indexing, schema, Core Web Vitals, video and multilingual architectures remain intact.
1. Confirm the latest production version and branch/package to modify. If newer than V43, diff/merge; do not overwrite newer work.
2. Add the 10 source PNGs to the working package and convert them to the exact 1200×630 WebP production filenames.
3. Create the 10 article directories by cloning/adapting the V43 article template, then insert approved copy, metadata, schema, links, FAQs, images and related cards.
4. Implement the 30 inbound contextual links on existing V43 pages. If the Turkish blueprint is in the same build, implement its Turkish inbound map as a separate language-local set; do not cross-wire anchors across languages.
5. Redesign /blog/ using the approved lean hierarchy and 6-chip, no-URL filter/search behavior.
6. Populate the hub library with all 38 article links and update CollectionPage/ItemList schema.
7. Wire article/hub CTA destinations only after confirming dedicated service URLs are live in the same build; otherwise use the safe /services/ fallback.
8. Update sitemap.xml and any sitewide generated inventories without removing existing URLs.
9. Pair all 10 English URLs with the approved Turkish equivalents when both are live; validate reciprocal hreflang, x-default and direct language-switch destinations.
10. Run full-site broken-link, canonical, hreflang, schema, image, metadata, H1, sitemap and route QA.
11. Run desktop/tablet/mobile visual QA, no-JS hub check, filter/search JS check, cookie-consent/analytics regression and performance spot checks.
12. Only after all QA passes: version the final production folder/ZIP according to the active project version, commit/push/merge/deploy under the Website Implementation Coordinator workflow.
Frequently Asked Questions
Frequently Asked Questions
Should I aim for a PageSpeed score of 100?
No. The objective is to improve real user performance and the actual failing metric, not to guarantee a perfect lab score.
Why does field data differ from Lighthouse?
Field data comes from real users across devices and networks; Lighthouse is a controlled lab test. Different conditions produce different results.
How long until Core Web Vitals field data changes?
Field metrics use rolling real-user data, so improvements are not reflected instantly. Validate lab fixes immediately and monitor field data over time.
