Search
Close this search box.
Search
Close this search box.

[ Solved ] “m” Domain Prefix Being Added in Google Search Results; Showing 404, Insecure, and Suspended Hosting Account

I recently encountered an issue migrating an old HTML/CSS-based website to a new server. There were some pre-configurations that I missed while documenting everything before the transfer.

Things went haywire when I ran desktop and mobile tests via Google search results. In other words, I searched Google, ensured the domain was indexed, and then clicked on the corresponding links in search results—all primarily to test the page loading and DNS resolution. Of course, I ran ping and nslookup tests in BASH, but I was doing a comprehensive set of tests.

The issue that popped up was that the domain was being indexed as m.domainname.com. When I tested the URL, it loaded a “Suspended…” account page, and of course, HTTPS:// wasn’t resolving as expected, so it was somewhat of a mess.

I rushed to set up Google Search Console to re-index the subdomain and other pages if old pages were still being indexed, but this was not the solution.

The solution was simply a reverse engineer of what I missed on the original cPanel server configuration. Lightbulb! And Argh!

This is what solved the issue:

  1. cPanel.
  2. Subsection “Domains” > “Domains” link.
  3. In the “Domain,” add m.domainname.com (this adds the new domain as a subdomain.)
  4. Selected “Share document root” as the desktop version index.html is configured with the following: <link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.domainname.com" /> This effectively instructs the browser to load that sub-domain if the screen width of the viewing device is below 640px. That’s what I missed and overlooked!
  5. Click “Submit” to save that domain as a stand-alone domain.
  6. Now, under “Domains” > “Redirects,” under “https?://(www.)?” select that newly entered domain: m.domainname.com.
  7. Under “Redirects to”: https://thedomain.com/m/ Which is the actual directory of the mobile website version.
  8. I unchecked the “Wildcard” and kept the default “Redirect with or without www.”
  9. I ran into a new issue where the SSL wasn’t registering (duh!) on m.domainname.com; web browsers were throwing fits about it. I re-issued the following under the validation type http-01 (but now including the m.-based subdomain.)
    • mail.domainname.com
    • www.domainname.com
    • m.domainname.com

Is the above the best solution? Could the configurations have been different? The basic answer: Yes, probably, and maybe. But, I was taking a website as-is, built old school with straight HTML and CSS files, no PHP, no Javascript, nothing else. Just plain old markup and styling. So, taking it as-is, in a straight project, without rebuilding the website or altering headers or other HTML, the above did seemingly solve the problem, and that is what I missed on the transition and inventory from the migration process.