A post in Reddit’s TechSEO forum describes a situation that gives legitimate site owners a familiar sinking feeling: rankings drop, traffic falls off a cliff, and Google Search Console shows a canonical URL that does not belong to the real site.
The site owner says their project, Nobella.app, started losing organic visibility after a third-party domain, olxlibre.com, appeared to be serving a “perfect copy” of the site through a reverse proxy. A reverse proxy is a server that sits in front of another server and fetches content on demand, then serves that content to visitors as if it were its own. In plain terms, it can mirror a website in real time without storing a static scrape.
The part that stings is the canonical issue. A canonical URL is the page Google treats as the primary version when multiple copies exist. In this case, the post claims Google selected the scam domain as canonical, treating the real domain as the duplicate.
What the Site Owner Noticed First
Traffic tanked, then Search Console told the ugly story
According to the post, the warning signs were not subtle. Organic traffic dropped sharply. Google Search Console then showed the cloned domain as the canonical URL. That combination often signals Google believes the copy is the “main” site.
The clone updated instantly when the real site changed
The site owner reported that content changes on the real site appeared on the clone right away. That detail points to a live proxy setup, not a one-time scrape. It also explains why standard “stop the scraper” advice can feel useless at first.
What They Tried, and Why Each Step Matters
Client-side JavaScript redirects
The owner added a JavaScript check that redirects visitors back to the real hostname. That can help human users who land on the fake domain. It does not fully solve search engine indexing because Googlebot can still fetch server-side HTML from the clone before any browser code runs.
Absolute canonical tags
The owner updated canonical tags to absolute URLs, such as https://nobella.app/page, instead of relative paths. That is a sound move. Absolute canonicals reduce ambiguity and create a clean, repeated signal across pages. It is one of the few on-page signals that Google can process at scale when duplicates show up.
DMCA submission through Google
A DMCA request is a copyright removal process. It is not an SEO tool, yet it can remove infringing URLs from search results. It can also create a paper trail that supports later escalations. It is often slow, and it is often worth doing anyway.
Submitting a disavow file
The owner submitted a disavow file tied to the scam domain. Disavow is a link-related tool. It tells Google to ignore certain backlinks when evaluating a site. It does not remove a cloned site, and it does not stop a proxy. In a proxy-canonical scenario, disavow can be a distraction unless the attack also includes spam links aimed at the real domain.
The Real Problem: The Proxy Origin Is Hidden
The owner said the next step is blocking the proxy’s server IP so the proxy receives a 403 Forbidden (access denied) or another error response when it tries to fetch content. That approach attacks the root mechanism: the proxy’s ability to retrieve pages from the real site.
The reported obstacle is common. The scam domain appears to sit behind Cloudflare, and the registrar setup is also part of the smokescreen. Cloudflare can mask the origin IP of the scam site, and it can also make attribution harder when abuse reports bounce around between providers.
What a Practical Response Plan Looks Like
Step 1: Confirm the proxy behavior with server logs
If you control the origin server, start with evidence. Check access logs for repeated fetch patterns that line up with the clone’s behavior. Look for unusual user agents, high-frequency hits, or consistent header fingerprints. If the proxy is using Cloudflare, you may still see consistent request behavior even if the source IP rotates.
Step 2: Tighten origin access rules
The goal is simple: let real users in, block automated fetchers that mimic a browser and pull full HTML repeatedly. Many site owners start with rate limiting and request filtering at the edge. Rate limiting caps request volume. Request filtering blocks patterns that match the proxy fetch behavior.
This is where “block by IP” can fail in practice. Many abusive fetch setups rotate IPs or use large networks. IP blocking still has value when logs show a stable cluster of sources. It is not the only lever.
Step 3: Strengthen server-side signals that prove ownership
Canonical tags help, yet Google can still get confused when it sees two identical sites. Add repeated ownership signals that the proxy cannot easily rewrite server-side:
- Make sure every page emits absolute canonicals and consistent internal links back to the real hostname.
- Use consistent structured data tied to your brand entity, such as Organization schema with the real domain listed as the URL.
- Publish a clear “About” or “Contact” page with unique, verifiable business details that appear across the web and match known profiles.
Step 4: Use provider channels that get action
DMCA is one lane. Abuse reporting is another. File complaints with the host, the CDN provider, and the registrar. Provide side-by-side proof: your real URL, their cloned URL, and timestamps. Screenshots help. Logs help more. When you write these reports, treat them like evidence for a dispute, not like a rant in a ticket form.
Step 5: Watch Google’s canonical choice like a hawk
In Google Search Console, track the canonical selection over time. Track indexing status. Track crawl stats. Track the “Duplicate, Google chose different canonical than user” type signals. The objective is to see the moment Google flips back to your real domain, then keep it there by repeating consistent signals.
Why This Attack Works at All
This type of negative SEO attack succeeds because it exploits two things at once. First, the proxy creates a duplicate that looks perfect. Second, canonical selection is an algorithmic decision, and algorithms can be fooled when the copy appears more accessible, more consistent, or simply gets crawled under conditions that make it look “cleaner.”
If this sounds unfair, that’s because it is. Google is good at de-duplication at web scale. It still makes bad calls, and the bad calls hit real businesses.
The takeaway is blunt: if someone reverse-proxies your site and Google starts treating the clone as canonical, you need two parallel tracks. One track blocks or degrades the proxy’s ability to fetch your origin. The other track floods Google with consistent ownership signals tied to your real hostname. Do both, document everything, and keep pressure on the providers until the clone stops working and Google reassigns the canonical where it belongs.