Listing deletion requests: what you actually owe a former advertiser who wants out

The message that says delete everything

Sooner or later a message like this arrives: someone who listed on your directory, sometimes years ago, asking for their profile, their photos, their account, and the search result that still turns up when their old working name is typed into Google, all gone. Some of these messages are calm. Some read like a legal threat. Many are just tired, written by someone who left the industry, changed careers, or simply wants a cleaner footprint, and would rather not explain why.

The instinct is to treat this as one click: find the listing, delete it, close the ticket. That instinct fails in both directions. It can make you promise something you cannot actually deliver, because a listing removed from your own database can still sit in a search engine's index or in a copy a scraper took months earlier. And it can make you erase records a different law requires you to keep, turning a reasonable personal request into a compliance problem you built yourself.

This is a different situation from a photo posted without the subject's consent, which a specific federal law already forces off a site on its own fixed clock. Here the person asking is very often the same person who created the listing, and what they want is the wind-down of something they built, not the removal of something done to them.

The request will keep arriving, which is exactly why it is worth a defined process rather than a fresh decision every time it shows up in a support inbox. An operator who improvises ends up in one of two bad places: too slow to meet a legal deadline, or too fast to notice that one of the records being deleted was never optional to keep.

What the law actually requires, and what it lets you keep

If the person asking is in the EU or the UK, GDPR's right to erasure applies once the regulation reaches your business at all, which depends on whether you have EU users or market to them, a question covered in more detail elsewhere. Where it applies, the clock is the same one that governs every data-subject request under the regulation: a response without undue delay and, in any case, within one month of receipt, extendable by two further months for a complex or high-volume request, as long as the person is told about the extension and the reason for it within that first month.

If the person is a California resident, and your business meets the CCPA's own thresholds for revenue or the volume of personal information it handles, the clock is 45 calendar days to respond to a verifiable deletion request, extendable once by another 45 days when reasonably necessary, again with notice given within the first window. A smaller operator with little California traffic may fall under none of these thresholds at all, but applying one consistent internal timeline to every request, regardless of where the person lives, is simpler to run than checking jurisdiction every time.

Both regimes stop you from acting on an unverified claim. Neither GDPR nor the CCPA lets a business delete, or refuse to delete, based on a bare email that merely asserts the sender is the account holder: both expect a reasonable method of checking that the person asking is who they say they are, scaled to how sensitive the data is. That verification step is not paperwork for its own sake; it is what stands between a genuine request and someone else deciding, on a stranger's behalf, that their listing disappears.

Both regimes also carve out an exception for what a business is independently required to retain. Age-verification records kept under federal record-keeping rules for adult content do not become erasable just because the person pictured later asks for their listing down. The same is true of records a payment processor or tax authority requires you to hold, and of whatever a business reasonably needs to detect and respond to fraud. A deletion request reaches the public-facing listing and the personal data tied to the advertiser's use of the site; it does not reach a file the law has separately told you to keep, for however long that law says to keep it.

The practical move is to stop treating the listing and the compliance file as one object. They live in different systems, answer to different clocks, and deserve different handling: the public listing comes down in full, while the backend record that another law requires stays exactly where it is, flagged with a short note explaining which specific retention duty it falls under. That note is what lets you show, months later if it is ever questioned, that you denied only the part the law actually let you deny.

What deleting the listing does not reach

Removing a profile from your own site and database does not reach a copy a search engine already crawled and indexed. Search engines recrawl pages on their own schedule, not yours, and until that recrawl happens, a page that no longer exists on your server can still show up in a search result with a cached snippet of text that is now wrong.

Google's tool for refreshing outdated content exists for exactly that gap, but it only works once the underlying change has already happened on your end: the page has to be gone, or genuinely different, before the tool can tell Google to update its record of it. It is not a lever that forces a still-live, unchanged page out of search results; a request submitted against a page you have not actually taken down will simply be denied.

A separate tool lets a person ask Google, at Google's own discretion, to drop certain personal details, such as contact information or an ID number, from search results even while the underlying page stays live. It is narrow by design: it does not cover a general request to remove someone's profile or bio, it is generally refused for pages on government, news, or education sites, and even where it succeeds it changes what Google shows, not what the original page still contains or what any other search engine indexes.

Whatever a third party already copied before the listing came down, a scraper's mirror, a cached review, a page saved by an independent archive, sits outside your control entirely. Reaching it means a separate request to that specific site, not one action that propagates everywhere, and some of those sites will not respond to a takedown request at all. Telling a former advertiser this plainly, rather than promising a clean internet, is the honest version of what you can actually deliver.

The identity problem: who is actually asking

A deletion request does not have to come from the advertiser to look like it did. An ex-partner, a competitor, or someone with a grudge can write an email claiming to be the account holder and ask for a listing pulled, and a directory that deletes on the strength of an unverified claim has just handed a stranger the ability to erase someone else's business.

The verification already built into onboarding is the natural anchor here. What a directory already holds on file from the identity check it ran before a listing went live is usually enough to confirm that a deletion request is coming from the same person, through the same account credentials or the same contact details already on record, rather than from a new and unverified claim arriving out of nowhere.

Where the request does not match anything on file, the honest answer is to ask for more before acting, not to split the difference by deleting part of the listing or pausing it quietly. A pause can look, to the actual advertiser, exactly like the account was hacked, and an unexplained one invites its own support ticket.

Being too slow to verify costs you a missed legal deadline. Being too fast to act on an unverified claim costs someone else their listing, with no deadline attached to getting it back once a stranger's request has already gone through. Of the two failure modes, only one of them is visible to the advertiser whose business just vanished, which is exactly why it deserves equal weight against the clock.

Building the workflow once, instead of deciding it every time

Give deletion requests one visible channel, a form or a dedicated support address, rather than letting them arrive scattered across email, chat, and whatever contact method a former advertiser happens to still remember. A scattered intake is how a request sits unanswered for three weeks before anyone realizes the clock on it started the day it arrived.

Start the clock on receipt, not on the day someone gets around to reading it, and track it against whichever deadline actually applies to that person, the shorter EU timeline or the longer US one. A simple log with a date and a due date catches the request that would otherwise slip past its deadline during a busy week.

Run the same short sequence every time: verify identity against what is already on file, take the public listing and photos down in full once identity is confirmed, flag the backend compliance records to their existing retention schedule instead of deleting them, and only then submit a request to refresh the search engine's record of the now-removed page.

Tell the person plainly what happened to each part of their request: the listing and photos are gone from the site, the search result will catch up on the search engine's own schedule, and a specific named category of record is being kept for a specific, nameable legal reason rather than out of convenience. That answer closes the loop honestly, and it is also the answer that holds up if the same person, or a regulator, asks again later.