cPanel gives you three ways to host more than one site on an account, and they behave differently in ways that matter for search engines. The default arrangement for addon domains, in particular, publishes every site at two addresses, and most people never notice.
The three types
Subdomain, shop.example.com. A section of your existing domain, with its own directory.
Addon domain: a completely separate domain hosted in the same account, with its own directory.
Parked domain (alias). A second domain showing the same site as your main one. No separate directory, no separate content.
An alias is the right tool when you own several spellings of your name and want them all reaching one site. Using an addon domain for that duplicates the site instead.
The addon domain trap
When you add an addon domain, cPanel creates a subdomain of your main domain pointing at the same directory.
So a site added as seconddomain.com is typically also reachable at seconddomain.example.com, and often at example.com/seconddomain as well.
Every page then exists at two or three addresses, all serving identical content. Search engines have to guess which is canonical, and any that link to the wrong one split the site's standing between addresses.
Nothing appears broken, which is precisely why it persists for years.
Fixing it
Two approaches, and the first is enough on its own.
Set a canonical tag on every page naming the correct address. This tells search engines which version counts and consolidates the signals.
<link rel="canonical" href="https://seconddomain.com/page/">
In WordPress this comes from the site address setting and any SEO plugin, so getting the site address right handles it. Changing the WordPress site URL has the detail.
Redirect the unwanted hostname to the real one, so the duplicate address stops serving content at all. A redirect in .htaccess keyed on the hostname does this. For writing it, see redirecting a domain or page.
Do the canonical first because it is safe. Add the redirect once you have confirmed which addresses are in use.
www and non-www is the same problem
The same duplication, on the same site.
example.com and www.example.com both work by default, and both serve the same pages. Pick one, redirect the other to it, and make sure your site's configured address matches the one you chose.
Which you pick does not matter. Being consistent does. A site whose internal links use one form while its canonical names the other is telling search engines two different things. Forcing HTTPS walks through doing both redirects in one rule.
Subdomain or subdirectory
A real decision when you are adding a blog or a shop to an existing site.
A subdirectory (example.com/blog/) is part of the same site and shares its standing directly. This is the better default for content that belongs to the same business.
A subdomain (blog.example.com) is treated as more separate. Right when the content genuinely is separate: a different brand, a different language, an application rather than content.
For a blog supporting your main site, use a subdirectory. It is the arrangement that helps the main site rather than building a second one alongside it.
Certificates cover what you tell them to
Every hostname you serve needs to be on a certificate, including the ones you would rather nobody used.
A visitor reaching seconddomain.example.com over HTTPS with no coverage gets a full browser warning, before your redirect ever runs, because the certificate is checked first.
So run AutoSSL after adding any domain and confirm each hostname is covered, rather than assuming. Managing AutoSSL deals with why failures only appear in a log.
Development sites need to be excluded
A staging copy at dev.example.com is a complete duplicate of your site, publicly reachable, and search engines will index it if nothing stops them.
A noindex header or meta tag is the reliable answer. Password protection also works and is stronger. Password protecting directories goes into it.
Do not rely on robots.txt alone. It asks crawlers not to fetch the page, which means they may still list the address without being able to see that it is a duplicate; the opposite of what you wanted.
Find out what is actually reachable
The check most people have never run.
For each site, try every address it might answer on: with and without www, the subdomain form of any addon domain, and the path form under the main domain.
curl -I https://seconddomain.example.com/
A 200 means that address is serving your site and is a duplicate. A 301 to the correct address means it is handled.
Run this once per site. It takes a couple of minutes and it is how the addon domain trap gets found; nothing else surfaces it. For reading the response, see understanding HTTP status codes.
Then check what is indexed
Search for a distinctive sentence from your site in quotation marks. If it appears at more than one address, the duplication is already in the index and the canonical tag is doing real work rather than theoretical work.
For adding and removing the domains themselves, How to Create and Manage Addon Domains explains the interface.
Each subdomain needs its own file, since the one at the main domain does not apply to it. How to Write a robots.txt and Control Crawling explains what belongs in each.
Decide the canonical form before adding anything
Duplicate content on one account is mostly the result of decisions made one at a time, each reasonable on its own.
Three choices, made once and written down, prevent nearly all of it. Whether the site answers with or without the prefix. Whether addresses end with a slash. And whether the secure form is the only form.
for u in http://example.com https://example.com http://www.example.com https://www.example.com; do
printf '%-32s %s\n' "$u" "$(curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}' "$u")"
done
Exactly one of those four should answer directly. The other three should redirect to it in a single hop. Any that answers with content is a second copy of the whole site.
Check what the pages say about themselves
Redirects handle the addresses visitors reach. The canonical tag handles what the page claims when it is reached correctly, and the two can disagree.
for p in / /about /blog /contact; do printf '%-12s %s\n' "$p" "$(curl -s "https://example.com$p" | grep -o 'rel="canonical" href="[^"]*"' | head -1)" done
Each page should name itself. The failure to look for is a whole section pointing at one address, which happens when a template was copied with its tag intact.
An addon domain serving a copy of another site's pages inherits its canonical tags too, so the duplicate declares itself part of the original. That is better than the alternative and it is still worth removing the duplicate rather than relying on it.
Find the copies you did not create deliberately
Accounts accumulate copies through ordinary work, and none of them announces itself.
ls -la ~/public_html/ | grep -iE 'old|backup|copy|new|test|v2|_bak' find ~/public_html -maxdepth 2 -name 'wp-config.php' | head find ~/public_html -maxdepth 3 -name 'index.php' -o -maxdepth 3 -name 'index.html' | head -20
A second configuration file is a second installation, and if it is reachable it is a second site with the same content on a different address.
These are also a security matter rather than only a search one, since an old copy is an unpatched copy. Removing them serves both purposes, and moving them out of the web root serves neither halfway. Auditing a WordPress site you inherited goes into what else turns up.