How a Random Domain Stole My Canonical and Removed My Site From Google

This issue started in a pretty frustrating way. The site for Structiq had been showing up in Google, then suddenly it seemed to vanish. At first it felt like one of those vague SEO problems where everything looks fine on the surface, but Google just decides not to show your site anymore. The twist was that it was not really an SEO content problem at all. It was a server and canonical problem.

The first real clue came from Google Search Console. The homepage inspection showed that the page was not indexed because it was considered a page with redirect, but the more important line was the canonical selection. Google had selected https://www.pivotapp.com.au/ as the canonical instead of Structiq. That meant Google believed Structiq was the duplicate version and Pivotapp was the primary version of the content.

Google did not invent that result out of nowhere. At some point, the Pivotapp domain was resolving to the same VPS IP address. Because the server was willing to answer requests for unknown hostnames, the Structiq site was being served when someone visited pivotapp.com.au. From Google’s point of view, it saw the same website on two different domains. Once that happens, Google has to pick one version as the canonical. Unfortunately, it picked the wrong one.

This kind of problem is more common than most people realize. VPS IP addresses get reused. Old DNS records can hang around. A random domain can still point at an old IP address, and if your server is not locked down properly, it may happily serve your site under that other domain. This does not usually mean anyone is attacking you. Most of the time it is just leftover DNS combined with a catch-all server configuration that is too permissive.

Once the issue was spotted, the first attempt to stop the wrong domain from loading the site was to add a default Nginx block that returned 444 for unknown domains. That did stop random domains from getting the site, but it also introduced another indexing problem. Google Search Console later reported server errors and duplicate pages without a user-selected canonical. Returning 444 is valid inside Nginx, but it is not a normal public-facing HTTP response. It can make crawl behavior less predictable and harder to interpret in search tools.

Checking the live Nginx configuration confirmed everything. There was a catch-all default virtual host for both HTTP and HTTPS returning 444. There was also a Structiq server block handling the real domain, but the setup was not as clean as it could be. On top of that, the HTTP logic for Structiq mixed redirects and a fallback 404 in a way that technically worked, but was messy and harder to reason about when debugging indexing issues.

The first proper fix was to make the default server return a normal 404 instead of 444. That way, if any random domain points to the VPS IP, the server does not serve the Structiq website and does not respond with an unusual Nginx-only status. It simply returns a standard not found response. After that change, visiting pivotapp.com.au no longer loaded the Structiq site. It showed a plain 404 page instead, which is exactly what we wanted.

The next fix was to make the server configuration much more explicit. All HTTP requests for structiq.pro and www.structiq.pro were redirected to the HTTPS version of the main domain. Then https://www.structiq.pro was redirected to https://structiq.pro. That leaves only one live canonical version of the site: https://structiq.pro. This matters because Google trusts consistency. If the same site can be accessed from several versions of a URL, indexing gets murkier. If everything resolves to one version, Google has a much easier job.

After reloading Nginx, the bad case was tested directly. Opening https://pivotapp.com.au no longer loaded the site. It returned a 404 page from Nginx. That was the turning point. It meant the accidental duplicate version of the site had been shut off at the server level. As long as Google eventually recrawls that domain and sees it no longer serves the same content, the canonical confusion should start clearing up.

The server fix was only half the solution. The website itself also needed to declare its preferred canonical URLs. That means adding a canonical tag in the HTML head so every page clearly says which URL is the original. For the homepage that would be Structiq. For other pages, each one should point to its own clean self-referencing canonical. In a Next.js app, the best way to do this is usually in the root layout metadata so the whole site inherits the correct domain.

Once the server behavior was cleaned up and the canonical direction was clear, the next step was to go back into Google Search Console and request indexing again. The homepage, pricing page, analyze page, and other key URLs were the first targets. The sitemap also needed to be submitted again so Google had a clean list of valid URLs to crawl. This part is important because fixes do not instantly change what Google believes. You still need to invite Google back to reprocess the site.

This did not mean the domain was ruined. It did not mean Google had penalized the site. It did not mean the brand had to be abandoned or replaced. It was a technical duplication and indexing problem, not a trust penalty. That distinction matters because it changes the response completely. Instead of panic, rebranding, or starting over on a new domain, the right move was to fix the infrastructure and then let Google catch up.

The bigger lesson here is that indexing problems are not always about content quality, backlinks, or on-page SEO. Sometimes the real issue lives lower down the stack: DNS, server blocks, redirects, host headers, and canonical signals. If Google sees your content in more than one place, it will make a choice. If you do not make that choice obvious, Google may pick the wrong version. That is why technical SEO still matters so much, especially for new sites on VPS infrastructure.

This was one of those annoying problems that feels much worse than it is. Watching a site disappear from Google is enough to make anyone think the project is dead. In reality, this was a cleanly explainable issue with a clean path to recovery. We identified the wrong canonical, found the server-level cause, blocked unknown domains from serving the site, enforced one proper domain, added canonical tags, and resubmitted the site to Google. That is the fix path. Now it is a matter of recrawl and reprocessing, not starting from scratch.