When I picked up a client website project on Monday afternoon, my first thought wasn’t whether the pages looked good—it was whether visitors would be tracked by ads

Last Wednesday at 4 p.m., I was in Hangzhou updating the official website for a six-person consulting team. The client list, inquiry forms, and access records were all sitting together, and I suddenly realized: if those visits came through ad redirects while the site’s tools retained visitor information long-term, the client’s company name could indirectly surface inside an ad system. I’ve been stuck here too. I used to think, “As long as nobody breaks in, we’re fine.” Later, I understood that tracking data and stolen data are two different risks. Since I’m not a security expert, this won’t be scary advice—just one check an ordinary person can start with.

This isn’t new software—it’s a site-identification method worth watching

Citizen Lab found that security agencies in several countries use advertising-based identification systems that recognize visitors through hidden information embedded in ads. In our small businesses, the common scenario is a client or visitor arriving through a search ad, while analytics tools, embedded content, or third-party scripts on the site may record or pass along those identifiers. For an independent entrepreneur running a website, service, or consultancy, the priority isn’t deciding who is monitoring us. It’s first understanding what our own site collects.

I know a virtual operations consultant named Lin Ran. Last year, she built a booking page for a dental clinic in Chengdu and found that the landing page had several analytics and advertising scripts attached. She didn’t delete everything immediately. Instead, she inventoried the scripts, removed the unnecessary ones, and wrote a one-page explanation in Chinese for the clinic. Since then, she has attached a “third-party script inventory” to similar projects, and clients have felt more reassured. She doesn’t work in security, and her approach was simple: know who owns every tool we put on the site.

Reproduce it today: ¥0 budget, about 30 minutes, technical barrier is knowing how to read the website admin menu

First, open the admin area of your client’s website or landing page and look for sections labeled “code,” “scripts,” “tracking,” or “analytics.” If you use a website builder, check “Settings—Website Code” or “Plugins/Apps.” Write down every third-party service, its purpose, and its owner. This usually takes 10 minutes.

Second, open a browser privacy-check page, or use your usual privacy-protection tool to see which tracking scripts the URL loads, then compare that with your admin inventory. Spend 10 minutes noting anything unfamiliar, unowned, or no longer used but still active. Third, make a normal visit in a browser’s private window and watch for requests that still appear. Finally, allow about 10 minutes to write the results in three columns: “keep,” “pause,” and “needs confirmation.” For scripts that touch client data, login details, or sensitive forms, give them to the site maintainer for confirmation before deleting anything.

If you don’t understand code at all, start with the inventory and screenshots. Don’t copy mysterious code from the internet. A free setup is enough for a basic audit, and it’s fine not to try today—especially if your personal portfolio hasn’t collected visitor information yet. Just keep the issue in mind.

Advice by stage: match the level of action to client size and risk

If you’re just starting: I’d first inspect my own portfolio and contact form for unfamiliar analytics tools. Twenty minutes is enough for an inventory and one visit, without touching payments or client data.

If you already have 1–2 clients: I’d add a third-party script review to every delivery checklist and give each client a one-page explanation: what is collected, how long it is retained, and why it is needed. Let the client confirm instead of quietly making the decision for them.

If you’re scaling: I’d create a shared ledger listing tool owners, data scope, and conditions for disabling a service. For sites involving login credentials, memberships, or health information, I’d ask a security consultant to review them again. Here, the goal isn’t to “delete everything”—analytics features may be essential to acquisition and learning from past performance.

My biggest takeaway wasn’t finding a universal switch. It was finally understanding that every small tool we add to a website can open a long-term data pathway. I can start with one page and spend half an hour getting clarity.