How a scan is made

What is fetched

The bot requests the URL you paste, follows a few redirects, and reads the HTML. If that HTML looks thin for a privacy notice, it tries one short headless render and reads links again. Thin here means no notice link, a script-drawn shell, or a block page. The budget for that render is about 12 seconds. If the homepage links to something that looks like a privacy notice, that page is fetched as HTML, without a second browser. A cookie page is used only when no privacy notice link is obvious. The scan does not crawl the rest of the site and it does not log in.

The user agent is DPDPBot/0.1. Pages larger than about 1.5 MB keep their start and end, up to a 5 MB cap, so a footer notice is not thrown away with the middle of a heavy document. Only ports 80 and 443 are allowed. Hostnames are resolved and checked again when the connection opens. Localhost, private ranges, link-local addresses, and cloud metadata addresses are refused, including the disguised forms of 127.0.0.1. Credentials in the URL are refused too. The same rules apply to redirects and to every request the headless browser would make.

Set DPDP_HEADLESS=0 and the scan stays on the static fetch. The linked notice page is still read with that static fetcher.

The checks

• Notice on the page. A visitor can find a privacy notice without already knowing where it lives.
• What the notice says. Purpose, the personal data involved, rights, withdrawal, retention, children, and a path to the Board.
• Someone to write to. A grievance contact or Data Protection Officer a person could actually reach.
• A visible choice. A consent or cookie interface in the HTML we could read. A missing banner is not a DPDP failure, and it is not a European reject-button test.
• Third parties. Analytics, ads, chat, payments, and Indian stacks such as CleverTap, MoEngage, and WebEngage.
• Forms. Name, email, or phone fields sitting on the page with no notice or consent cue beside them.
• HTTPS and headers. The public connection is encrypted, plus a light look at common browser headers.

Notice wording is matched in the text a visitor could read: purpose, categories of personal data, access, correction, erasure, nomination, withdrawal, retention, children, a grievance contact, and a complaint to the Data Protection Board. Third-party tags include common analytics and advertising hosts plus Indian products such as CleverTap, MoEngage, WebEngage, Netcore, and the usual payment widgets. A match is a host on the page, not a judgment about the contract behind it.

The score

Every report starts at 100. A high finding deducts 16, a medium finding deducts 9, and a low finding deducts 4. Info findings are shown and do not move the score. The result is floored at 0.

• 80 to 100. Strong public signals.
• 60 to 79. Partial public signals.
• 40 to 59. Thin public signals.
• 0 to 39. Few public signals.

If no privacy notice can be read, the scanner does not also pile on a separate miss for every notice clause. It reports that the notice was not available, and it still looks at the homepage for a contact, a form, tags, and the connection.

When the fetch is thin

A high "notice not found" is used only after a substantial public homepage was actually read and still had no notice candidate. If the headless render is unavailable or fails, a missing notice link is not reported at high confidence. The report says the public HTML we could read did not show a notice link, and it adds fetch-limited when the page looks incomplete. It does not say the organisation has no notice.

A missing cookie banner is informational. It is not a DPDP consent failure and it is not a European reject-button test. The consent-ui finding stays low only when analytics, advertising, or marketing tags are present with no visible choice. Where Section 7 legitimate uses apply, consent may not be required at all. A present banner can still be the wrong kind of consent. The scan cannot see that from the HTML.

Keyword matches miss notices written in a way the patterns do not expect, and they can match a sentence that is not doing the legal work. The tag list is indicative. An unknown host is not called clean. Security headers are a light public slice of reasonable security safeguards, not an audit of how data is stored once it arrives.

What the report will not say

It will not tell you that you comply with the DPDP Act. It will not tell you that you breach it. Reports are unlisted. Anyone with the link can open one. This demo stores them in a local SQLite file. There is no public directory.

Where monitoring would start

The free scan is one fetch. The thing that is not built yet is a schedule: repeat the same checks, diff the notice, and alert when a tag or a form changes. There is no billing. The email field on the homepage and on a report writes a row on this machine and sends nothing.

Run a scan or read the sample report. Mehfil & Co is fictional.