DEV Community: MG Content Labs

Auditing Structured Data, Canonicals and Hreflang with Chrome DevTools Console Snippets

MG Content Labs — Sun, 04 Oct 2026 13:31:43 +0000

On-page technical elements, such as canonical tags, meta robots directives, hreflang annotations and JSON-LD schema, live in the page's where visitors never look. A single mistake can de-index a page, split ranking signals across duplicates or stop rich results from appearing. Chrome DevTools can inspect all of it, and the Console and Snippets features can speed the work up considerably.

Inspect the head in the Elements panel

Open DevTools and select Elements. Expand and review:

title> and
link rel="canonical">
meta name="robots"> and
link rel="alternate" hreflang>
script type="application/ld+json">
Open Graph and Twitter Card tags_

Remember to look at the rendered DOM. If a plugin or script rewrites tags after load, the Elements panel shows the final result while page source may show something different.

Canonical tag audit

Every indexable page should have exactly one canonical tag, in the head, pointing to an absolute URL that returns a 200 status. Check for:

Multiple canonicals (often added by both a theme and an SEO plugin)
Relative URLs instead of absolute
Canonicals pointing to redirected, 404 or noindexed URLs
Paginated pages all canonicalized to page one, which can hide deeper content
Parameter URLs that fail to canonicalize to the clean version

A quick Console check:

document.querySelectorAll('link[rel="canonical"]')

This returns every canonical node. A result of more than one is a red flag.

Meta robots audit

Find the robots meta tag and read its directives. A stray noindex left over from staging is one of the most expensive SEO mistakes. Console check:

document.querySelector('meta[name="robots"]')?.content

Also confirm the same page isn't being blocked by an X-Robots-Tag header, covered in the Network panel.

Hreflang validation

Hreflang tells Google which language or regional version to show. Rules to verify:

Each version references itself as well as the alternates
Annotations are reciprocal: if page A points to B, B must point back to A
Language and region codes are valid (for example en-gb, not en-uk)
Include an x-default for unmatched users
URLs are absolute and return 200

List all annotations with:

[...document.querySelectorAll('link[rel="alternate"][hreflang]')].map(l => [l.hreflang, l.href])

Compare the output with the alternate pages. Hreflang can also be placed in HTTP headers or XML sitemaps, so check those if none appear in the head.

Structured data audit

Find JSON-LD blocks in the Elements panel or extract them with:

[...document.querySelectorAll('script[type="application/ld+json"]')].map(s => JSON.parse(s.textContent))

The Console prints each block as an expandable object. Review that:

The JSON parses without errors (a missing comma breaks the whole block)
The @type matches the page, such as Article, Product, FAQPage or LocalBusiness
Required and recommended properties are present
Marked-up content is actually visible on the page
Values such as price, rating and dates match the visible content

Then validate with Google's Rich Results Test and the Schema Markup Validator. DevTools finds and extracts the markup; those tools tell you eligibility. Note that Google has narrowed the display of some rich results over time, such as FAQ and HowTo, so check current documentation before promising SERP features to clients.

Save reusable Snippets

Open Sources, then Snippets, and create a new snippet. Paste a script that collects title, description, canonical, robots, hreflang and schema into a single table:

console.table({
title: document.title,
description: document.querySelector('meta[name="description"]')?.content,
canonical: document.querySelector('link[rel="canonical"]')?.href,
robots: document.querySelector('meta[name="robots"]')?.content,
h1Count: document.querySelectorAll('h1').length
});

Run it with Ctrl+Enter on any page. Snippets persist in your browser, so you can audit page after page in seconds.

Extra checks worth adding
Heading structure: one clear H1 and a logical hierarchy
Images: alt attributes present and descriptive
Internal links: descriptive anchors and no nofollow where you don't intend it
Pagination and parameters: consistent canonical handling
Scaling beyond one page

DevTools is ideal for spot checks and debugging. For site-wide audits, pair it with a crawler such as Screaming Frog or Sitebulb, then use DevTools to investigate the specific URLs the crawler flags.

Conclusion

Canonicals, robots directives, hreflang and schema decide how search engines interpret and display your pages. A few lines in the Console let you check them quickly, and a saved Snippet turns it into a routine. Add this to your pre-launch checklist so small tag errors never reach production.

FAQ

Can a page have more than one canonical tag?
It shouldn't. Conflicting canonicals may be ignored, so keep exactly one.

Do I need hreflang for a single-language site?
No, only for sites with multiple language or regional versions.

Is JSON-LD better than Microdata?
Google recommends JSON-LD because it's easier to maintain and separate from the visible HTML.

Why does my schema pass validation but show no rich result?
Eligibility isn't a guarantee. Google also weighs content quality, page type and its current rich result policies.

Are DevTools Snippets safe to run?
Yes, they run only in your browser on the page you choose. Still, never paste scripts from sources you don't trust.

Lighthouse and Chrome DevTools: A Mobile-First Technical SEO Audit Workflow

MG Content Labs — Sun, 04 Oct 2026 13:27:36 +0000

Google uses the mobile version of your content for indexing and ranking, so a mobile-first audit is the default way to test a site. Chrome DevTools has everything needed to build a repeatable workflow without paid software: the Lighthouse panel, device emulation and the Coverage tab.

Why mobile-first matters

With mobile-first indexing, if your mobile page hides content, drops structured data or removes internal links that the desktop page has, Google may not see them. Mobile also exposes the hardest performance conditions: slower CPUs, weaker networks and smaller screens.

Step 1: Use Device Mode

Click the device toolbar icon (or press Ctrl+Shift+M). Choose a preset like a mid-range Android phone, or set custom dimensions. Then check:

Parity of content: are headings, body copy, images and alt text identical to desktop?
Parity of links: is navigation reachable, or are links missing on mobile?

Viewport: the page should include .

Tap targets and font size: buttons need adequate spacing and text should be readable without zooming.

Intrusive interstitials: full-screen popups that cover content on arrival can harm usability.

Use the Sensors and Rendering tabs to test further. You can emulate different media features, such as dark mode or reduced motion.

Step 2: Run Lighthouse

Open the Lighthouse panel, choose Mobile, and tick Performance, Accessibility, Best Practices and SEO. Use an Incognito window to avoid extension interference, then click Analyze page load.

The SEO category checks basics such as:

A perfect SEO score means the basics are in place. It does not mean the page will rank. Treat it as a floor, not a ceiling.

Step 3: Read the Performance opportunities

Lighthouse lists specific fixes ranked by estimated savings. Focus on the ones tied to Core Web Vitals:

Reduce unused JavaScript and CSS
Properly size images
Serve images in next-gen formats
Eliminate render-blocking resources
Avoid enormous network payloads
Reduce main-thread work

Run each test three times, since results vary slightly, and compare the median.

Step 4: Find waste with the Coverage tab

Open the Command Menu and type "Show Coverage." Click reload and the tab reports, for every JavaScript and CSS file, the percentage of bytes actually used during that load.

Red bars show unused code. Large third-party bundles or a global CSS framework used for a single component are typical offenders. Fix them with:

Code splitting so each page loads only its own scripts
Tree shaking and removing unused libraries
Extracting critical CSS and deferring the rest
Replacing heavy plugins with lightweight alternatives

Remember that coverage depends on the interactions you perform, so test key flows such as opening menus before you decide code is unused.

Step 5: Check accessibility overlaps

Accessibility and SEO share a lot of ground: descriptive alt text, logical heading order, clear link text and good contrast. Lighthouse's accessibility audit often flags issues that also improve crawler understanding.

Step 6: Document and prioritize

Build a simple audit table with columns for issue, affected template, severity, effort and owner. Prioritize by template reach. A flaw in a product page template that serves 5,000 URLs outranks a one-off issue on a single blog post.

Step 7: Retest after changes

Re-run Lighthouse after every fix cycle and save the reports. In Lighthouse you can export the report as JSON or HTML for stakeholders. For ongoing monitoring, Lighthouse CI can run audits automatically on each deployment.

Limits of Lighthouse

Lighthouse is lab data. It tests one page, on one simulated device, at one moment. It can't tell you how real users experience your site, and it won't evaluate content quality, backlinks, search intent or topical authority. Combine it with Search Console, field data and manual review.

Repeatable monthly workflow
Pick your top five templates by traffic
Run Lighthouse mobile on a representative URL for each
Check mobile and desktop parity in Device Mode
Review Coverage for unused code
Log issues, assign owners and retest after release

Conclusion

Lighthouse, device emulation and the Coverage tab make a capable, free toolkit for mobile-first SEO audits. Keep the workflow repeatable, prioritize by template, and always treat lab results as a guide to investigate, not a final verdict.

FAQ

Is a 100 Lighthouse SEO score required for ranking well?
No. It confirms technical basics only; rankings depend on many other factors.

Why does my score change between runs?
Lighthouse is affected by network and CPU variability, so average several runs.

Does Google still use separate mobile URLs?
Google indexes mobile content first. Responsive design is the recommended approach.

What does the Coverage tab measure?
The share of each CSS and JavaScript file executed or applied during your test session.

Should I audit desktop at all?
Yes, but start with mobile because it's what Google primarily evaluates.

Using the Chrome DevTools Network Panel for Technical SEO: Status Codes, Redirects and HTTP Headers

MG Content Labs — Sun, 04 Oct 2026 13:21:32 +0000

Much of technical SEO happens before a single word of content is read. Servers answer requests with status codes and HTTP headers that tell crawlers whether a URL exists, where it moved, whether it can be indexed and how long it can be cached. These signals are invisible on the page itself, but the Chrome DevTools Network panel exposes all of them.

Here is how to use it as a free technical SEO audit tool.

Set up the Network panel
Open DevTools, select the Network panel and tick Preserve log, so redirects are not cleared during navigation. Tick Disable cache for fresh results. Right-click the column header and add useful columns: Status, Domain, Protocol, Initiator, Content-Encoding and Response Headers such as x-robots-tag and cache-control.

Check status codes

Load the URL and look at the first request (the document). The status tells you a lot:

200: the page is served normally.

301: permanent redirect. Passes signals to the destination and is the standard for moved content.

302/307: temporary redirect. Fine for genuinely temporary moves, but often misused for permanent ones.

404: not found, correct for pages that don't exist.
410: gone, a clear signal for intentionally removed pages.

5xx: server errors. Sustained 5xx responses can cause Google to slow crawling.

Beware the soft 404: a "page not found" template served with a 200 status. The browser view looks like an error, but the Network panel reveals the 200.

Trace redirect chains and loops

With Preserve log on, enter an old URL such as the HTTP version of your homepage or a non-www address. Each hop appears as its own row. A healthy path is one redirect straight to the final canonical URL. Problems include:

Chains: A to B to C to D. They waste crawl budget and slow users. Collapse them into a single hop.
Loops: A to B to A. The browser reports too many redirects, and crawlers give up.

Mixed protocol hops: HTTP to HTTPS to www to trailing slash, in separate steps. Combine the rules.

Test the four classic variants: http://, https://, with and without www, and with and without a trailing slash. All should end in one canonical version.

Inspect indexing headers

Click the document request and open the Headers tab. Check the response headers for:

X-Robots-Tag: this can apply noindex or nofollow at the server level, and it is easy to miss because it never shows in the HTML. It is common on PDFs and staging leftovers pushed to production.
Link: rel="canonical": a canonical declared in the HTTP header must agree with the HTML canonical tag.

Content-Type: make sure HTML is served as text/html with correct character encoding.

Vary: User-Agent: signals that content may differ by device, which matters for mobile SEO.

Conflicting directives, such as an indexable HTML meta tag alongside a noindex header, are a classic cause of "why isn't this indexed?" mysteries.

Verify compression

Compressed responses load faster, which supports performance and crawl efficiency. Check the Content-Encoding header on HTML, CSS and JavaScript. You should see br (Brotli) or gzip. Resources missing compression show a transfer size close to their full size. Images and other already-compressed formats don't benefit from it.

Review caching

The cache-control header decides whether returning visitors reload files. Static assets such as images, CSS and JS with versioned filenames should carry long lifetimes, for example max-age=31536000, immutable.

HTML typically gets a short lifetime or revalidation. Poor caching rarely hurts crawling directly but affects repeat-visit speed and your Core Web Vitals field data.

Confirm HTTP/2 or HTTP/3

With the Protocol column visible, you'll see h2 or h3 for modern connections and http/1.1 for older ones. Modern protocols allow multiplexing, which helps pages with many resources.

Find mixed content and third-party bloat

Sort by Domain to see who loads what. Look for:

HTTP resources on an HTTPS page (mixed content), which browsers may block Dozens of third-party requests slowing the page Broken images or scripts returning 404, which also create wasted crawl requests

The Initiator column shows which script triggered each request, helping you identify the tag or plugin that's responsible.

Simulate scenarios

Two features help with testing:

Request blocking: right-click a request and choose "Block request URL" to see how the page behaves if a script or stylesheet fails.

Network conditions: change the user agent to check for bot-specific redirects or cloaking mistakes. This is a diagnostic only, as it doesn't fully replicate Googlebot.

Quick audit checklist
One-hop redirects from all URL variants
200 status only on live pages, with true 404/410 elsewhere

No stray X-Robots-Tag: noindex
Canonical headers match HTML canonicals
Brotli or gzip on text resources
Sensible cache-control rules
No mixed content or failing resources

Conclusion

The Network panel reveals the server-side layer of SEO that crawlers experience first. A ten-minute check of status codes, redirects, headers and compression can uncover problems that no content change will ever fix.

FAQ

Does a 302 redirect hurt SEO?
Google treats long-standing 302s much like permanent redirects, but a 301 states your intent clearly, so use it for permanent moves.

How many redirects are too many?
Aim for one. Google follows a limited number of hops, and each adds delay.

Can a header block indexing without me seeing it in the page?
Yes. X-Robots-Tag: noindex is applied via headers only, so check it in the Network panel.

What is a soft 404?
A page that looks like an error but returns a 200 status code.

Is Brotli better than gzip?
Brotli usually compresses text better, and most modern browsers support it.

JavaScript SEO: How to Debug Rendering and Indexing Issues Using Chrome DevTools

MG Content Labs — Sun, 04 Oct 2026 13:12:46 +0000

Modern sites built with React, Vue, Angular or similar frameworks often deliver an almost empty HTML shell and build the page in the browser. Google can render JavaScript, but rendering happens in a second wave that can be delayed, and any script failure can leave content invisible. If a page ranks poorly despite strong content, rendering is one of the first things to check.

Chrome DevTools lets you see the page the way a rendering engine builds it. This guide covers practical checks any SEO can run without writing code.

Step 1: Compare source HTML with rendered HTML

Right-click the page and choose View Page Source. This is the raw HTML the server sent. Now open DevTools and look at the Elements panel, which shows the rendered DOM after JavaScript has run.

Compare the two for the elements that matter:

Title tag and meta description
Canonical tag
Main heading and body copy
Internal links
Structured data

If important content exists only in the Elements panel, it depends on JavaScript. That isn't automatically a problem, but it means indexing relies on Google's renderer succeeding every time.

A fast shortcut: search the page source for a distinctive sentence from your body copy. No match means client-side rendering is injecting it.

Step 2: Disable JavaScript and reload

Open the Command Menu (Ctrl+Shift+P or Cmd+Shift+P), type "Disable JavaScript" and run it. Reload the page.

What remains is your baseline. Ask:

Is the main content still visible?
Do navigation links still appear?
Are product listings, prices or reviews gone?

Pages that go blank without JavaScript carry the highest risk. Consider server-side rendering (SSR), static generation or hybrid rendering for those templates. Remember to re-enable JavaScript afterwards.

Step 3: Check that links are real links

Search engines discover URLs by following elements. Many JavaScript apps navigate using click handlers on

or elements, which crawlers can't follow.

In the Elements panel, inspect your menu, pagination and category links. You want:

Shoes

You don't want an element with only an onclick handler, or an href="#" that depends on script to route. Fragment-only URLs (#/page) are also a problem, because Google generally ignores the fragment.

Step 4: Hunt for blocked and failing resources

Open the Network panel, reload and sort by status. Look for:

Blocked or failed JavaScript and CSS files (4xx or 5xx). If a script that builds content fails, Google sees an incomplete page.

API calls returning errors. If your content comes from an API and it times out or rate-limits, rendering produces blanks.

Resources disallowed in robots.txt. Googlebot needs access to the scripts and styles that render your page. Blocking /js/ or /assets/ can break rendering.

You can also check the Console panel for red errors. A single uncaught exception early in the bundle can stop everything after it from running.

Step 5: Watch for content that needs interaction

Googlebot doesn't click, scroll infinitely or hover. Content that appears only after a user action may never be seen. Test these patterns:

Infinite scroll: provide paginated URLs as a fallback, each with a real href.

"Load more" buttons: make sure the loaded items also exist on crawlable paginated pages.

Tabs and accordions: content present in the DOM but visually hidden is generally fine. Content fetched only on click is not.

Lazy-loaded images: use native loading="lazy" or IntersectionObserver implementations that trigger without scrolling gestures.

Step 6: Throttle to expose timing problems

Rendering budgets are limited. In the Network panel, set throttling to "Slow 4G" and the Performance panel to CPU 4x slowdown, then reload. If content only appears after several seconds, there is risk that a renderer with a timeout will not wait. Reduce bundle sizes, split code and prioritize above-the-fold content.

Step 7: Confirm with Google's own tools

DevTools shows how your browser renders the page, not how Googlebot does. Always cross-check with the URL Inspection tool in Search Console. Use "Test Live URL" and then "View Tested Page" to compare the rendered HTML and screenshot. This catches differences from user-agent handling, blocked resources and rendering timeouts.

Overriding your user agent via Network conditions can reveal servers that deliver different content to bots. Treat this as a diagnostic aid only, since it doesn't replicate Googlebot's infrastructure.

Rendering strategy cheat sheet
Content-heavy, SEO-critical pages (blogs, categories, products): SSR or static generation

Logged-in dashboards: client-side rendering is fine, since they aren't meant to rank

Mixed pages: render core content on the server and hydrate interactive widgets on the client

Conclusion

JavaScript isn't an SEO enemy, but it adds failure points. By comparing source and rendered HTML, disabling scripts, validating links, checking network failures and confirming in Search Console, you can find indexing gaps long before they cost you traffic. Build this checklist into every site launch and migration.

FAQ

Can Google index JavaScript content?

Yes, Google renders JavaScript. But rendering can be delayed, and errors or blocked resources can leave content unindexed.

Is server-side rendering required for SEO?

Not strictly, but it's the most reliable option for important pages and helps performance too.

Why is my content in DevTools but missing in Google?

Common reasons are blocked resources, rendering timeouts, content requiring interaction or failed API calls.

Does DevTools show exactly what Googlebot sees?

No. Use it to diagnose, then verify with the URL Inspection tool.

Are hash URLs bad for SEO?

Generally yes. Google typically ignores the fragment, so use the History API for clean paths.

How to Diagnose Core Web Vitals Problems with Chrome DevTools (LCP, INP and CLS)

MG Content Labs — Sun, 04 Oct 2026 13:00:56 +0000

Core Web Vitals are Google's measurements of real-world page experience. Search Console and PageSpeed Insights tell you that a page is failing, but not why. Chrome DevTools answers the why. It lets you record a page load, replay an interaction and see exactly which resource, script or element caused the delay.

This guide shows technical SEOs and developers how to diagnose the three Core Web Vitals directly in the browser. The "good" thresholds are:

Largest Contentful Paint (LCP): 2.5 seconds or less
Interaction to Next Paint (INP): 200 milliseconds or less
Cumulative Layout Shift (CLS): 0.1 or less
Start with field data, then reproduce in the lab

Field data comes from real users, through the Chrome User Experience Report (CrUX). Lab data is what you collect yourself in DevTools. The two will rarely match exactly, so use field data to decide which pages and metrics to fix, and use DevTools to find the cause.

Open a page, press F12 (or Cmd+Option+I on Mac) and go to the Performance panel. The live metrics view shows LCP, CLS and INP for your current session, and can compare them with CrUX field data for the same URL. If the two disagree badly, your test conditions probably don't match your audience. Fix that before you start optimizing.

Set realistic test conditions

Your development machine is fast and your users' phones are not. Before recording, open the Performance panel settings and apply:

CPU throttling: 4x or 6x slowdown to approximate a mid-range mobile device
Network throttling: "Fast 4G" or "Slow 4G"
Disable cache: tick this in the Network panel to simulate a first visit

Record in an Incognito window so extensions don't distort the trace.

Diagnosing LCP

LCP measures when the largest visible element, usually a hero image or headline block, finishes rendering. To investigate:

Click Record and reload in the Performance panel.
Find the LCP marker in the Timings track and click it. DevTools highlights the element.
Review the LCP breakdown: time to first byte, resource load delay, resource load duration and element render delay.

Each phase points to a different fix:

High TTFB: slow server response, no caching, unoptimized database queries or a missing CDN.
Long resource load delay: the browser discovered the image late. This is common when the hero is a CSS background image or injected by JavaScript. Use a normal tag, add fetchpriority="high" and consider a preload hint.
Long load duration: the file is too heavy. Serve modern formats such as WebP or AVIF, and use responsive srcset sizes.
Long render delay: render-blocking CSS or JavaScript is holding the paint. Inline critical CSS and defer non-essential scripts.

A frequent technical SEO mistake is lazy-loading the LCP image. Check the Network panel: if your hero image carries loading="lazy", remove it.

Diagnosing INP

INP replaced First Input Delay as a Core Web Vital in March 2024. It looks at the latency of interactions across the whole visit, not just the first one, so it is harder to pass.

To test it:

Start a recording.
Perform the interaction you suspect: open a menu, click a filter, type in a search box.
Stop recording and look at the Interactions track.

Each interaction splits into three parts: input delay, processing time and presentation delay. Long tasks, marked with a red corner on the Main thread flame chart, are the usual culprits. Click one to see which function ran, and look for:

Heavy event handlers that run synchronously
Third-party tag manager scripts, chat widgets or A/B testing tools
Large DOM trees that make style recalculation slow

Common fixes are breaking long tasks into smaller chunks (setTimeout or scheduler.yield()), debouncing handlers, moving heavy work to a web worker and removing or delaying third-party scripts.

Diagnosing CLS

Layout shifts annoy users and cost you a Core Web Vitals pass. In DevTools:

Open the Rendering tab (Command Menu, then "Show Rendering") and tick Layout Shift Regions. Shifting areas flash blue as you load or scroll.
In the Performance recording, open the Layout Shifts track and click each shift to see which nodes moved and by how much.

The usual causes and fixes:

Images and video without dimensions: add width and height attributes or CSS aspect-ratio.
Late-loading ads or embeds: reserve space with a fixed-height container.
Web fonts causing text reflow: use font-display: swap with a size-matched fallback, or preload critical fonts.
Injected banners (cookie notices, promos): overlay them or reserve their space instead of pushing content down.
Validate and monitor

After fixing, re-record under the same throttling and confirm the metric moved. Then wait. CrUX field data is a rolling 28-day window, so Search Console's Core Web Vitals report will take weeks to reflect your work. Consider adding the web-vitals JavaScript library to collect real-user data from your own site and spot regressions earlier.

Conclusion

Chrome DevTools turns Core Web Vitals from abstract scores into specific, fixable causes. Set realistic throttling, break each metric into its phases and fix the largest phase first. Repeat the process on your highest-traffic templates, since one template fix often improves hundreds of URLs.

FAQ

Do Core Web Vitals directly affect rankings?

They are part of Google's page experience signals. Content relevance still matters most, but when pages are otherwise similar, better experience can be a tiebreaker.

Why do my DevTools scores differ from Search Console?

DevTools is lab data from one device and network. Search Console uses field data from real users across devices over 28 days.

Which metric is hardest to pass?

For many sites it is INP, because it evaluates every interaction and is heavily influenced by JavaScript weight.

Can I test pages behind a login?

Yes. DevTools runs in your authenticated browser session, so it works on logged-in pages that public tools can't reach.

How often should I re-test?

After each significant deployment, and at least monthly for key templates.