A takedown is not verified when the notice is sent. It is not verified when the provider acknowledges the notice. It is verified when you check the object that was supposed to change.
Use this protocol.
Step 1: Save the before-state
Before enforcement, record:
- exact source URL
- direct file URL, if known
- screenshot
- search result
- redirect target
- seller or account identity
- date and time
This gives you something to compare against.
Step 2: Recheck the exact source URL
Open the original URL in a normal browser session.
Then, if appropriate, check in a private/incognito session so cached login state does not confuse the result.
Record what happens:
- page loads with the infringing material
- page loads but content changed
- redirect
- 403
- 404
- 410
- login wall
- timeout
- domain no longer resolves
Do not assign a final state yet.
Step 3: Follow redirects
If the URL redirects, follow the new destination.
A redirect can point to:
- a replacement piracy page
- another domain
- a new file
- a homepage
- a seller page
- a shortener
If the same content is still reachable, the original URL is not a meaningful source-removal success.
Step 4: Check the direct file separately
If you know the file-host or cloud-storage URL, test it separately.
A page can be removed while the file remains live.
A file can be removed while the page remains online.
Record both.
Step 5: Interpret common access states carefully
200
The endpoint returned content.
Check whether the infringing material is still there.
301 or 302
The URL redirects.
Follow it.
403
Access is forbidden. This can mean:
- permissions
- geo restriction
- bot blocking
- authentication
- another access rule
It does not automatically prove a takedown.
404
The URL was not found at the time you checked. It does not prove permanent deletion.
410
The server is signaling that the resource is gone. Still check for mirrors and replacements.
Timeout or DNS failure
This can be temporary. Recheck before calling it removed.
Step 6: Check Google and Bing independently
Search removal is separate from source removal.
Check:
- Bing
- exact title/product query
- site-specific query if useful
- the exact URL where appropriate
If Google removed the result but the source is still live:
Search delisted
If the result simply does not appear and you do not know whether Google acted:
Not observed in search
Do not overstate the result.
Step 7: Check mirrors and replacements
Search for:
- product title
- course title
- book title
- filename
- version
- release name
- seller handle
- known aliases
If the same copy appears somewhere else after a previous resolution:
Reappeared
Step 8: Assign one outcome per object
Use a table like this:
| Object | Outcome | Evidence | Last checked |
|---|---|---|---|
| Piracy page | Source removed | 404 at source | Sep 23 19:30 |
| Direct file | Still active | File link resolves | Sep 23 19:31 |
| Search delisted | Confirmed result absent after request | Sep 23 19:35 | |
| Bing | Still indexed | Result visible | Sep 23 19:36 |
| Mirror | Reappeared | New URL found | Sep 23 19:40 |
Do not collapse these into one "case closed" field.
Step 9: Use an indeterminate state when needed
Sometimes the evidence is not clear.
Use:
Indeterminate
when:
- site times out intermittently
- access is geo-restricted
- login state changed
- a provider says it acted but the public state is unclear
- the URL is temporarily unavailable
- you cannot safely verify the direct file
Uncertainty is better than false certainty.
Step 10: Recheck based on recurrence risk
There is no universal schedule. Use the product's risk.
Examples:
Software with frequent releases
Recheck around new versions.
Course launch
Check more closely during the first weeks if the leak is actively spreading.
Ebook
Check mirrors and search periodically after source action.
Reseller case
Check seller identity and replacement listings.
A simple verification log
Use these fields:
Case:
Protected product:
Source URL:
Direct file URL:
Action taken:
Recipient:
Reference:
Date submitted:
Source check:
File check:
Google check:
Bing check:
Mirror check:
Current state:
Confidence:
Last checked:
Next action:What a trustworthy provider report should show
At minimum:
- finding
- exact URL
- evidence
- action
- recipient
- submission date
- current source state
- current search state
- escalation state
- last verification
- recurrence
A report that only says "notices sent" is activity reporting. It is not outcome reporting.
WatchMesh keeps those states attached to the case so you can see what actually changed.
If you want to check the current state of existing piracy before deciding what to do next, start a Free Evidence Audit.
Official references
- Google legal-removal guidance: https://support.google.com/legal-help-center/answer/13887279
- Bing copyright form: https://www.bing.com/webmaster/contentremovalform/showcontentremovalform
- U.S. Copyright Office Section 512: https://www.copyright.gov/512/