On-Page SEO and Redirect Checker

How to use this checker

1. Paste one page address. Copy the address exactly as a visitor would open it, including any redirect you want to test. A homepage address is a good starting point, but any single public page can be checked on its own.
2. Run the check and wait for the fetch to finish. The checker requests the page from our server, follows each redirect one hop at a time and records the status code, timing and server address for every step before it reads the final page.
3. Read the summary and the redirect chain first. Confirm that the final address is the address you expected, that the final status is a successful response and that the chain is as short as it should be. A wrong destination makes every later check misleading.
4. Work through the page checks and the issue list in order. Issues are grouped from high to low priority and each one shows the evidence found on the page together with a concrete fix, so you can deal with blocking problems before cosmetic ones.
5. Fix the page, then check it again. After you publish a correction, run the same address once more and compare the new report with the old one. Export the report as JSON or CSV before you start if you want a record to compare against.

Worked example: checking example.com

The simplest way to see what this tool does is to check a page whose behaviour is already well known. The address https://example.com is a short demonstration page maintained for use in documentation, so its result is deliberately plain and easy to read. Running the check fills in the address for you and submits the form, exactly as if you had typed it yourself.

Expect a short result. There is a single hop with no redirect in between, because the address you enter is already the final address, and the final status is a successful response. The page does carry a title, so the title check shows a value together with its character length instead of reporting a missing title. It declares no canonical link, so the canonical check reports that none was found and the issue list explains why adding one is worth considering. Read the rest of the report in that same spirit: each row states what was found on this particular fetch, neither more nor less, and the heading outline, link counts and social tag sections simply reflect the very small page that was returned.

Load sample

What this checker is, and why it matters

An on-page check answers a narrow but important question: when a search engine, a browser or a person follows this exact address, what do they actually arrive at, and what does that destination page say about itself? The answer is often assumed rather than verified. A page is edited, a template is updated, a redirect is added during a redesign, and everyone continues to describe the page as it used to be. This checker replaces that assumption with a fresh fetch. It requests the address you give it, follows the chain of redirects hop by hop, and then reads the final page closely — its title, description, canonical link, indexing directives, headings, images, links, social tags and structured data — and sets out what it found, with the problems separated from the raw facts.

That separation matters because not every imperfection carries the same weight. A missing title, a page that blocks indexing, or a chain that ends in an error can keep an otherwise good page out of search results altogether. A slightly long description or an incomplete set of social tags, by contrast, mainly affects how the page looks when it is shown or shared. Presenting findings in priority order, each with its evidence and a suggested fix, lets you spend effort where it changes the outcome first. The evidence is just as important as the verdict. Seeing the exact title text and its length, the exact canonical address, or the exact hop at which a chain changes protocol tells you what to correct, rather than leaving you to guess which setting the checker objected to.

Redirects deserve special attention because they sit between the address people share and the page they reach. Each extra hop adds waiting time, gives something another chance to fail, and can quietly change the destination — from secure to insecure, from one domain to another, or from the intended page to a generic fallback. A chain that grew by accident during successive site changes is a common finding, and it is invisible from inside a content management system, where every individual rule looks correct. Laying the chain out as a table, hop by hop with status codes and timings, makes the whole journey visible at once.

Used regularly, a checker like this becomes part of ordinary publishing hygiene. Run it after a template change, after a migration, after editing a page that matters to you, or whenever a page stops performing and you need to rule out the basics before investigating further. It will not judge your writing, your design or your strategy, and it deliberately offers no single score, because a single number would hide precisely the detail you need. What it offers instead is a clear, checkable account of one page on one occasion — and that account is the proper starting point for fixing anything.

Common problems, errors and limitations

Some findings come up again and again. Long redirect chains usually mean an old address has survived several site changes, with each new redirect pointed at the previous destination instead of the current one. A canonical link pointing somewhere unexpected often comes from a copied template or a site address setting that was never updated after a move. Missing alternative text for images is frequently an upload habit rather than a technical fault: the field is simply skipped when nobody is required to complete it. None of these needs specialist knowledge to put right once the report has shown you the exact values involved, which is why each issue pairs its evidence with a plain fix.

Checks can also fail before any analysis begins, and the error message will tell you which kind of failure occurred. An address may be malformed, use a scheme or port this tool does not fetch, fail to resolve in DNS, point to a private or otherwise non-public address, redirect more times than the limit allows, or take longer than the time limit to answer. Those refusals are deliberate safeguards and accuracy limits, not faults in your page. Only public pages on the standard web ports can be fetched, the whole chain must complete within a short fixed time budget, and very large responses are analysed only up to a size cap, in which case the report warns you that the page was truncated. Pages that need a login, pages assembled entirely by scripts after loading, and signals such as how real visitors behave are outside what a single server fetch can see. Results are also cached briefly, so a repeat check immediately after publishing a change may show the previous fetch; the report tells you when a result came from the cache. Finally, a clean report means only that the checks performed found nothing to flag. It is not a promise about rankings, traffic or approval by any search engine.

• Blocked address: the address resolves to a private, loopback or reserved address, so it is refused for safety.
• Too many redirects: the chain exceeds the hop limit, which usually indicates a loop or a chain that needs shortening.
• Timed out: the site did not finish responding within the time budget for the check.
• Rate limited: the hourly allowance for checks has been reached; wait for the period named in the message, then try again.

Frequently asked questions