A small business website in Singapore has two readers it was not designed for. One is the expectation, set out in Singapore's Personal Data Protection Act, administered by the PDPC, that personal data is handled with care. The other is the software that now fetches the site on a customer's behalf and tries to read it. The two look unrelated. In practice, three of the decisions they turn on are the same decision: whether analytics needs a cookie, whether the privacy notice is linked from every page, and whether there is a named contact for data matters. Make each the simple way and both readers are served.
One caveat before anything else. We are not lawyers and this is not legal advice. What the Act requires of a given business depends on what that business does with data, and the obligations vary. The PDPC's own material at pdpc.gov.sg is where to find out what applies to you. What follows is the technical side: what a scanner can measure, and why the simpler configuration tends to score better.
Cookieless analytics is the easy path
Most small sites carry analytics for one reason: to know how many people came and which pages they read. Whether that needs a cookie is a product choice. Cookieless analytics counts page views and events without setting a cookie or storing a persistent identifier on the visitor's device. Where that is enough, the reason to ask the visitor anything disappears, and with it the banner.
The banner matters to an agent because an agent cannot click it. Check A6, "no hard interstitial", worth 2 points in pillar A, reads the homepage (the rendered HTML where a headless capture succeeded, otherwise the raw response) and tests it against a short list of markup patterns. One group matches consent-management markup: id="onetrust, osano, cookieyes, cookie-consent, cookie-banner and cc-window. The others match a Cloudflare challenge, the reCAPTCHA or hCaptcha loaders, the text "Just a moment..." and a "please enable JavaScript" notice. If only the cookie-wall marker fires, the check scores 1 of 2. If a CAPTCHA or challenge marker fires, it scores 0. The evidence lists markers, so you can see which pattern tripped. Cookie walls are interstitials walks through the reasoning.
That is the route we took. Our privacy notice states that we use Plausible Analytics, which is cookieless and does not track individuals across sites or sessions, that we set no advertising or profiling cookies, and that this is why no consent banner has been shown. It is a configuration choice, not a legal position. A business whose site does set tracking cookies has a different question to answer, and that question belongs to the PDPC's guidance rather than to this post.
The practical test is short. List every cookie your site sets and every third-party script it loads. For many SMEs the honest list is one analytics tag and perhaps a chat widget. Swap the tag for a cookieless one, link the chat out rather than embedding it, and the site has nothing left on its face to ask consent for.
A privacy notice that is linked, not just published
Check D3, "policies discoverable", 4 points, rated Low effort, does not read the notice. It looks for the link. The engine joins the raw HTML of every fetched page that returned 200 and looks for an href containing privacy; that is 2 points. The other 2 depend on site type. A shop needs an href containing shipping or delivery and another containing return or refund; everyone else needs one containing terms, tos or conditions. The evidence records hasPrivacy, hasTerms, hasShipping, hasReturns and siteType.
Two consequences follow for a small site. The notice must be linked from the pages the crawl reaches, which in practice means the footer, on every page, rendered by the server rather than assembled by a script after load. And an SME that ships physical goods should link shipping and returns as well as privacy and terms whatever the crawler decides it is, because the classification can surprise you and four links make it irrelevant. The policies post covers how the site type is decided.
What the notice says is between you, your adviser and the PDPC. That it exists at a stable URL and is linked from every page is the part a program can check, and the part an agent uses when weighing whether a site is what it claims to be.
A data protection contact you can find
Our privacy notice publishes dpo@agentfriendlyrank.com and says two things about it: that Singapore's PDPA requires this contact to be publicly available, and that the address is monitored by a person rather than a filter. It is also the address the notice gives for access, correction and deletion requests, with a stated response within 30 days and no fee. We say only that much because it is what the notice says. Whether your business needs the same arrangement is a question for the PDPC's guidance.
For the scanner, a published contact is half of check D2, "verifiable identity", 4 points. The first 2 come from a contact route: an href whose path contains /contact, /about, /impressum or /legal, or any mailto: link, anywhere in the crawled pages. A mailto: to a data protection address in the footer satisfies it on its own. The other 2 need an Organization type in the JSON-LD with a sameAs carrying at least one URL, a company profile a model can use to corroborate the site. The evidence records contactDiscoverable, hasOrganizationSchema and sameAsCount.
A footer that carries a contact link, a mailto: to the data protection contact, and links to privacy and terms therefore settles most of D2 and D3 at once. It is the same footer the PDPA expectation would have you build anyway.
The other checks that matter for a small business site
The whole rubric applies, but a handful of checks carry most of the risk for a typical SME site.
Hosting defaults (A2, A5). Many small sites sit behind a CDN or a site builder whose bot protection blocks AI crawlers by default. The robots.txt says Allow; the edge says 403. A5 fetches the homepage as three crawlers and records the status codes; A2 parses robots.txt for six named agents. Both are one-setting fixes once found.
Server-rendered content (A7). If the site builder draws the page in the browser, the plain fetch an agent makes sees a shell. The ratio of raw visible text to rendered text needs to reach 0.8 for full marks.
Who you are (B2, D5). An Organization or WebSite node whose name matches the title element and og:site_name. For a shop, Product and Offer markup with price and availability.
Transport (D1). Valid TLS and an HSTS header. Most hosts provide the first; the second is a line of configuration.
None of this is specific to Singapore. What is specific to Singapore is that the data protection decisions and the agent readiness decisions point the same way, so an SME does not have to choose between them.
Who is telling you this
AgentFriendlyRank is a service of Socio360, a sole proprietorship registered in Karnataka, India. We market to customers in Singapore and the United States, and our privacy notice applies Singapore's PDPA, India's DPDP Act 2023 and applicable US state privacy laws at once, taking the most protective requirement where they differ. We say that plainly, as our about page does, rather than manufacturing a local presence we do not have. If you want to talk about a specific site, contact us.
Check your own site
Run the free scan and read A6, D2 and D3 with the evidence beside each. The definitions are on the methodology page under discovery and access and trust and freshness.