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.
Top comments (0)