ToolFlect Inspect

Scan your website. Fix what matters first.

Run a fast public website check and get a repair plan matched to your platform. No account required.

A full public address. If you leave the scheme off, https:// is added before the scan.

ToolFlect Inspect checks publicly visible website configuration. It does not perform penetration testing or guarantee security, SEO rankings, or accessibility compliance.

What a repair looks like

One finding, in full, exactly as the scanner produced it.

Recorded from the ToolFlect Inspect test fixture minimal-site.com — a synthetic page in our own test suite, not a customer site. The finding, the evidence, the steps and the verification line below are the scanner's real output for that page, copied without editing.

High priority Confidence: high Area: Search & Sharing

The page has no title tag

Guidance cites a published standard, not a menu path

Source: HTML Standard, "The title element" (whatwg.org); and Google Search Central, "Title links" documentation

What is wrong

There is no <title> element in the HTML source. Search engines and browsers have nothing to label the page with, so they invent one from page content or the URL.

Why it matters

The title is the headline a search result shows. Without one, the result is likely to be something you did not choose.

Evidence

No <title> element was found in the document source.

How to fix it

  1. Open the template or CMS field that renders this page and find the head section.
  2. Add a single title element inside the head.
  3. Describe this specific page in the words someone would search for.
  4. Make it unique across the site — do not reuse another page’s title.

How to verify the fix

View the page source in a browser and confirm the change is present in the returned HTML.

Why we say this

Menu paths change between plugin versions, plans, and themes. When we can't cite a documented path, we say so rather than send you to the wrong screen. This is a deliberate choice.

Why we don't guess

Plenty of scanners will confidently tell you to open a menu that was renamed two versions ago. That wastes your time and makes the whole report less believable, so this one labels every piece of repair guidance with exactly how it was obtained.

  • Verified against vendor documentation

    15 records cite a page from the vendor that was fetched and read, with the date it was read. The page is linked, so you can check it yourself.

  • Guidance cites a published standard, not a menu path

    70 records rest on a specification — an RFC, the HTML Standard, or a search engine's own documentation — named with the section that defines the behaviour. There is no vendor screen to point at, because the setting may not have one.

  • Manual step — this platform's documentation didn't cover this case

    26 records are marked for manual verification. Nothing in that platform's documentation covers the case, so the steps are deliberately platform-neutral.

  • We searched 2 sources on 2026-09-11 and found no documented step-by-step path

    32 records record a search that was actually made. The vendor documentation either names the screen without documenting the sequence, or says nothing about it. The number of sources read, and the date, are written into the badge.

What a provenance label is, and is not

It is information about how the guidance was obtained. It is not a fault, not a warning about your website, and it never affects a finding's severity. None of the four labels above is an error, and none of them is shown in a warning colour anywhere in a report.

What you get

Four areas, all read from the response the public internet already receives.

  • Search & Sharing

    The page title, description, canonical address and sharing preview that a search engine or a chat app will use when this page is linked.

  • Public Security Configuration

    The response headers and cookie attributes a browser reads before it decides how far to trust the page. Visible configuration only — nothing is probed or attacked.

  • Performance Basics

    How much was transferred, how many separate files the page asks for, and what has to load before the first paint. Measured from the response, not from a browser.

  • Detected Platform

    Which CMS, theme, plugin or CDN is serving the page, so the repair steps can name your own screens instead of describing them in the abstract.

Supported platforms

Repair guidance is written per platform, and how well each one is verified differs. The counts below are computed from the repair knowledge base itself, so this page cannot claim more coverage than it has.

  • Cloudflare

    Full step-by-step guidance.

    15 repair records. 13 cite a page from Cloudflare's own documentation that was fetched and read, including the click sequence for creating a Response Header Transform Rule.

  • Rank Math

    Named screens, and general guidance.

    11 repair records. Rank Math's documentation was searched for each one and names the fields involved, but does not document a step-by-step sequence, so every record says so rather than sending you to a screen we could not confirm.

  • Yoast SEO

    Named screens, and general guidance.

    10 repair records, in the same position as Rank Math: Yoast's own help pages were read and are cited, and they name the fields, but they do not document a full click sequence for these checks.

  • WordPress

    General guidance only.

    12 records for WordPress itself, without a plugin. 8 are platform-neutral steps, because the setting these checks concern is usually owned by the theme or a plugin rather than by WordPress core. Where WordPress does document the screen, the record cites it.

  • Kadence

    General guidance only.

    5 records. No Kadence article confirming a settings path for these checks was found, so every record gives the platform-neutral steps and says a manual step is needed.

  • Elementor

    General guidance only.

    6 records, in the same position as Kadence: no Elementor article confirming a widget settings path was found, so the records are platform-neutral and flagged for manual review.

  • Hostinger

    General guidance only.

    6 records. One cites a Hostinger tutorial for forcing HTTPS with .htaccess. The rest are platform-neutral, because the setting is generally owned by the application rather than by the hosting panel.

Every check also has platform-neutral guidance: all 78 rules have a record that applies to any site, so a scan always produces steps to follow even when the platform is unknown. Where a platform's documentation was searched and came up short, the record says which of those two situations you are in.

How it works

  1. Enter your website address

    One public address. No account and no email.

  2. We run a safe public scan

    One ordinary request, read the way any visitor's browser would read it. It never logs in, never submits a form, and never probes for vulnerabilities.

  3. You get a prioritized repair plan

    Ordered by how much each finding matters, discounted by how confident the scan is, with the steps for your platform — or an honest note that we have no verified steps.

  4. Rescan to verify the fix

    Change something, scan the same address again, and compare the two results.