All webmaster tools Single-page server snapshot

Site Health Check

See what one public HTML response reveals about search essentials, page structure, accessibility hints, delivery, and defensive headers—with every score explained.

HTTP or HTTPS · standard ports · up to five redirects

Privacy: the address is submitted by POST and page content is held only for this response. The hostname is resolved through Google Public DNS. The global safety limiter stores timestamps only—no requester address or target—and stale state is removed on later requests or system cleanup. The target sees WPFlunky’s IP and user agent.

A practical report, without inflated promises

Enter one public page. WPFlunky fetches its raw HTML once, follows only validated public redirects, and explains every result. It does not render JavaScript or pretend to measure Core Web Vitals.

What it seesStatus, redirects, bounded HTML, common metadata, markup patterns, and selected response headers.
What it does not seeRendered layout, scripts after load, subresources, user interactions, other pages, or real-user performance.
How it stays safePublic DNS validation and pinning, manual redirects, TLS checks, strict limits, and no unsafe fallback client.
HOW TO USE THE SNAPSHOT

What a one-page website health check can tell you

This report examines the original HTML response that a server sends for one public URL. That makes it useful for finding foundational problems that affect crawling, search snippets, document structure, and browser delivery before you move on to a full-site crawl or a rendered performance test.

Start with access and indexing signals

A useful page must first return an intentional HTTP status and resolve through a sensible redirect chain. The check also looks for a title, meta description, canonical URL, robots instructions, language, mobile viewport, and selected social metadata. These signals help crawlers understand the preferred page, but they cannot force a search engine to index or rank it.

Review structure in the delivered HTML

Headings, image alternatives, form labels, landmarks, and structured-data syntax can reveal avoidable markup problems. They are only indicators: a passing snapshot is not a WCAG audit, and JavaScript may change the final document after load. Test important templates with a browser, keyboard, screen reader, and representative users.

Use delivery checks as a starting point

Content type, response size, timing from WPFlunky, and selected security or caching headers describe this single request. They do not measure Core Web Vitals or real visitors. For performance decisions, follow up with field data and a browser-based lab test from locations that match your audience.

Turn findings into the next website fix

Correct broken access or accidental indexing rules first, then make the visible heading, title, description, and canonical agree about the page’s purpose. Re-run this check after deployment and verify site-wide patterns separately. Need implementation help? Build a clean head with the Meta Tag Builder, then confirm crawler rules with the Robots.txt Maker.