Welcome to the Q&A Forum

Hmmm, there seem to be a number of significant disconnects here.

First, an AutoSSL will be perfectly fine for your purpose. There's actually no difference between how a free SSL performs and a paid one. The encryption is the same. The thing is, the whole point of AutoSSL is that it is a two or three click installation process. It literally takes three or four minutes, not eight hours. Your developer must be assuming he is going to have to generate and install an old-fashioned certificate in the completely manual method that used to be necessary. That's simply not the case with AutoSSL in cPanel.

Second, the actual domain name migration is going to need to be made up of two overlapping parts. The first part is getting all of the website files and objects to run under the new domain name and HTTPS protocol. The second part is getting all of the external elements adjusted and corrected so they are also using the new domain name.

For the first part of that process, there are WordPress plug-ins that will do the basic website migration in about an hour. These plug-ins will handle changing all of the URL references to the new domain name, and updating them to reflect the HTTPS as well. Then it's necessary to do quality assurance on the site to make sure that any small exceptions or manually created URLs get caught and corrected as well.

The final step is getting the DNS and redirects in place so that all of the old domain traffic is correctly redirected to the new domain and pages. In addition, all of the external/third-party tools that are used with the site must be updated. Things like Google Analytics, Google Search Console, AdWords, ad servers and other tools must be updated to reflect the new domain name and protocol. In addition, all the external profiles you use must be updated as well for things like Facebook, Twitter etc. If your site relies heavily on Facebook share counts for social proof, there are also extra steps that must be taken to salvage those counts after the migration. And finally, you must decide how you're going to handle company email with the change in domain name. This relates to both the company email mailboxes, and the way email is handled from forms on the website.

Doing a domain and https migration like this is definitely a significant undertaking and needs a proper, well-thought-out project plan for implementation, But the actual moving of the files and website to the new domain name and HTTPS is certainly not a 30-hour process. It's managing all the rest of the elements of the migration to ensure both usability and SEO are maintained that take up the time.

Hope that all makes sense?

Paul

The more you can differentiate these two sites, the better they will each perform in their own specific markets, CP.

First requirement will be a careful, full implementation of hreflang tags for each site.

Next, you'll need to do what you can to regionalise the content - for example changing to UK spelling for the UK site content, making sure prices are referenced in pounds instead of dollars, changing up the language to use British idioms and locations as examples where possible. It'll also be critical to work towards having the reviews/testimonials from each site's own country, rather than generic, This will help dramatically from a marketing standpoint and also help differentiate for the search engines, so a double win.

And finally, you'll want to make certain you've set up each in their own Google Search Console and used the geographic targeting for the .com site to specify its target as US. (You won't' need to target the UK site as the .co.uk is already targeted so you won't' get that option in GSC.). If you have an actual physical address/phone in the UK, would also help to set up a separate Google My Busines profile for the UK branch.

Bottom line is - you'll need to put in significant work to differentiate the sites and provide as many signals as possible for which site is for which country in order to help the search engines understand which to return in search results.

Hope that all makes sense?

Paul

Yup, the requirement for these kinds of links is to use nofollow on them, Roger. They're worth leaving in place (assuming you have the clients' permission) for their potential referral value, but even without the nofollow, they'd have little SEO value anyway as Google heavily devalues sitewide footer links like that. Best to be safe from having them considered manipulative by making them nofollow.

If you want to add another layer of usefulness, add UTM tracking to the links so you can easily distinguish visitors from those links in your Analytics. That way you can assess how those visitors are performing once they reach your site. I'd actually recommend going one step further and creating a custom landing page that is specifically optimised for visitors you know have already seen a website you designed.

Make sense?

Paul

tl:dr leave things as they are

This is one of those cases where the ever-changing web makes it hard for the automated tools to keep up, Ben. It's always been best practice to have both the www and non-www version of pages redirect to the canonical HTTPS version in a single hop.

But then the advent of HSTS threw a bit of a wrench into the works, specifically with respect to the HSTS Preload list created by Google and now used by other browsers as well. Just implementing HSTS isn't the main issue, but if you then submit the site for inclusion on the Preload list, the browser is going to care that the HTTPS redirect come first, then the redirect to the correct canonical (www or non-www) version happens after. This is because the Preload list basically commands the browser ahead of time "if you're not directed to the HTTPS connection first, refuse to connect at all".

Current best practice is to run your site under HTTPS with HSTS set for a short TTL for a period of time to insure all is working well. Then when you're sure all is performing as expected, you lengthen the TTL setting out to a year a more ( by adjusting the HSTS header settings), and request submission to the preload list.

The reason you want to do this in stages is that it's very hard to go backwards. Once a browser has received a long-TTL HSTS header or you're on the preload list, it can take a very long time (many months) to try to step back from the HTTPS settings if you encounter a problem, leaving your site full of errors & security warnings. (This can happen with sites that discover unfixable mixed content issues after migrating to HTTPS, for example, such as a real estate site finding out their property listing tools don't support HTTPS yet, a case that came up in another Q&A question just a short time ago)

Bottom line, if you're going to take the final sensible step in the process by getting added to the HSTS Preload list, you're going to want to leave the settings as is and not worry about the extra redirect. Unless there's a significant server issue, the extra redirect will only add milliseconds, and using HSTS and getting added to the preload list actually reduces the server calls by at least one, so will offset the redirect.

Whew! Sorry to be long-winded, but wanted to provide the background so you could understand the reason for the contradictions you are encountering.

Paul

P.S. As long you make sure all links under your control are using the proper canonical HTTPS URLs (especially internal site links - rewrite them in the database, don't make a plugin handle them), only a very small portion of visitors are ever likely to experience the extra redirect anyway.

Answered a similar question a couple of weeks ago, Tom.
https://moz.com/community/q/can-we-add-header-tags-followed-by-header-tags-without-text-in-between-best-practice

Bottom line is that header tags are semantically designed to introduce the following section of content. If the following content is more headers, it breaks this semantic paradigm. Not a critical disaster, but not best practice either.

That help?

Paul

You've asked a great question, Wagada. The fact that the version of the content on Constant Contact's page has already been indexed does mean that you'll have a duplicate content challenge, but there are ways to address it.

The whole problem with duplicate content is not that it generates some kind of penalty, (it doesn't) it's just that search engines then have to decide which of the dupe pages they should point to in the search results.

The version you publish on your own site already has several things going for it, and you need to add additional signals to help the search engines prioritise your site's version. First, at least part of the rest of your site is probably already talking about the same topics, so there will be more relevance there than from the random topics on Constant Contact. Plus, if your newsletter is like most, it will be linking back to your site, giving the SEs another signal.

The biggest thing you can do to get your site's page considered as the canonical (primary) version is to get at least a few links pointing to it. Social media links can be very useful for this, especially from Google Plus, but a solid link or two from other sites will go a long way as well. Also, make sure your page does NOT link to the CC page - that way there's a clear authority signal that only travels one way.

For future reference, if you're going to publish newsletter content on your own site, there are a couple of steps to take in preparation.

• Publish the content on your own site a day or a couple of days in advance
• Use the Fetch and Render tool in GSC to help it get crawled and indexed before sending the newsletter (SEs take "first published" date into account when trying to ascertain which page to return in results.)
• Make sure it's strongly-linked internally - maybe even put a link to the newsletter content page on your homepage before sending the newsletter
• Get a few incoming links to the newly-published page before the newsletter goes out.
• Use the newly published page's address in the newsletter's preheader text link where it says "If not showing up well in your email, you can read this in your browser" so the dupe page actually links back to the page you want to be considered primary.
• Or best yet, do the above and also turn off the newsletter archive on Constant Contact altogether and make the prepublished page on your site the only version. This is the best, but obviously takes a bit more work and preparation to pre-publish. It also offers the massive benefit of delivering those newsletter viewers who do want to read in a browser to your own pages where you can induce further activity/conversions. Though it should be said that in the newsletters I've managed, very few people click the "view in browser" links anymore anyway.

Hope all that makes sense?

Paul

While a good solution if it were possible, unfortunately ESPs like Constant Contact don't give you any way to alter the content of the of their pages. And canonical tags must be in the or they'll be ignored.

Great! I'd really like to hear how it goes when you get the switch back in.

P.

Where the words are in a meta-description is not a ranking factor, Icarus. Think of meta descriptions as your opportunity to make a mini sales pitch for your page on the search results page.

You'll want to use the primary keywords that explain what the page is about, as that just makes sense, but artificially forcing them to be the first words can make the meta-description look very spammy and artificial in many cases.

There is a benefit to having the words in the meta description that your visitor actually searched for, as they will show up in bold in the description, but remember they'll also be showing in bold in the page title too, so overdoing/forcing it can contribute to looking artificial, which can turn visitors off.

Also to keep in mind, especially after last week's Google change to longer meta-descriptions, is that Google will often change the meta description if they think the one you wrote isn't a good match for the searcher's query. So keeping them effectively descriptive of the page, instead of keyword-stuffed, and having a good call-to-action in the description is still your best bet.

In your specific example, if the page is primarily about the wholesale distribution of that product, it makes perfect sense to include that in the description. Whether those should be the first words depends entirely on whether you can write a natural-sounding description text that way. I often use such words to expand on what the page is about in a way that often can't be effectively handled in the much shorter, more restrictive page title.

Hope that helps?

Paul

This is relatively true for page title, but the OP is asking about meta-descriptions.

Further to Patrick's point, remember that a page passes its authority to other pages by dividing up the page's "power" (ranking authority, or your term Pagerank) and distributing it relatively evenly through all the outgoing links on the page. So if you have a bunch of links to external sites, you're sending a significant amount of that "power" to other sites instead of distributing to your own pages.

The web is built on the effectiveness of hyperlinking, so this isn't an argument to never link out from your site, but having a number of not-very-useful external links on every page dissipating your own page power unnecessarily isn't a good strategy. (And no, no-following those links doesn't change the fact they send your page authority away instead of keeping it for the other links.)

Hope that helps clarify?

Paul

You can't noindex a URL by protocol, Gaston - adding no-index would eliminate the page from being returned as a search result regardless of whether HTTP or HTTPS, essentially making those important pages invisible and wasting whatever link equity they may have. (You also can't block in robots.txt by protocol either, in my experience.)

There's a very simple solution to this issue - and no, you absolutely do NOT want to artificially force removal of those HTTPS pages from the index.

You need to make sure the SSL certificate is still in place, then re-add the 301-redirect in the site's htaccess file, but this time redirecting all HTTPS URLs back their HTTP equivalents.

You don't want to forcibly "remove" those URLs from the SERPs, because they are what Google now understands to be the correct pages. If you remove them, you'll have to wait however long it takes for Google and other search engines to completely re-understand the conflicting signals you've sent them about your site. And traffic will inevitably suffer in that process. Instead, you need to provide standard directives that the search engines don't have to interpret and can't ignore. Once the search engines have seen the new redirects for long enough, they'll start reverting the SERP listings back to the HTTP URLs naturally.

The key here is the SSL cert must stay in place. As it stands now, a visitor clicking a page in the search engine is trying to make an HTTPS connection to your site. If there is no certificate in place, they will get the harmful security warning. BUT! You can't just put in a 301-redirect in that case. The reason for this is that the initial connection from the SERP is coming in over the "secure channel". That connection must be negotiated securely first, before the redirect can even be read. If that first connection isn't secure, the browser will return the security warning without ever trying to read the redirect.

Having the SSL cert in place even though you're not running all pages under HTTPS means that first connection can still be made securely, then the redirect can be read back to the HTTP URL, and the visitor will get to the page they expect in a seamless manner. And search engines will be able to understand and apply authority without misunderstandings/confusion.

Hope that all makes sense?

Paul

Your Schema markup has been implemented using a number of different methods, Lindsay.

The basic website and Organisation Schema is implemented through the settings in the Yoast SEO plugin.

In addition, there's Local Business/Organisation Schema implemented manually using JSON-LD markup added to the site's footer, probably via a footer widget. These two partly duplicate and partly contradict each other, so should be corrected by choosing one version and completing it fully.

Those are just a couple of examples - investigating the implementation methods for all the other Schema types would take a proper site audit to discover and confirm the implementation method.

Fortunately, Google does provide an effective way to confirm whether or not the existing implementations are correct. In the site's Google Search Console under Search Appearance > Structured Data, Google will show you all the structured data (Schema) it has discovered, and let you know if there are any implementation errors and on which pages.

Is that what you were looking for?

Paul

It's likely the other site is trying to use the redirects to mask their manipulative link building. (Which doesn't work, by the way.)

Short answer - no this isn't a good idea.

Hope that helps?

Paul

Shareaholic and Social Warfare (paid) plugins are the ones I'm familiar with, Sameer. There is also a paid add-on for Sassy Social Share plugin that will accomplish this too. Others may have also added this capability.

P.

It's never a good idea to rely on the search engines "figuring out" confusing/contradictory signals from your website, vtmoz. While they claim they can do it in some cases, in reality, they very frequently get it wrong. (Though I've never seen any indication from Google that it makes any effort to find any connecting ownership signals between dupe sites when deciding whether to index a dupe. That would be way outside the scope of the crawler.)

So yes, it's entirely possible that wholly duplicate website is causing ranking and authority issues. Assuming what you mean by a site for "testing new optimisations" is a development website for testing new code before deploying to the live site, you'll need to get the dev site placed behind a password-protected login, or at the very least, have no-index meta tags added to every page. Once those are in place, you can use Google Search Console to request removal of the site from the index to hopefully speed things up. It's possible that when you had the dupe site before, it didn't get fully indexed, but this time it did, which would be why you're seeing more problems now. And having a dupe site in the index can definitely cause problems with the original site, as well as the dupe.

There's no guarantee removing the dupe site from the index will immediately resolve all the problems you are having, but leaving the dupe site in place in the index is just too big a risk. You'll still have to look deeper into what else may be causing or exacerbating the ranking issues.

Paul

Putting keywords in the GMB business name has a very high risk associated with it. It's against Google Terms of Service and they say they will suspend any account they catch doing it.

But as you note, many businesses are doing it and getting away with, at least for some period of time.

So the question becomes "how much risk is the client willing to accept"? Because if they get caught, their account gets wiped out and they lose all the work they've done to build up ranking, reviews, images etc for their GMB page.

I tend to agree with Miriam Ellis who just wrote about exactly this on Monday in her post. Build a good-quality GMB page within Google's guidelines to ensure long-term survival, including optimising for the "housecall" terms in description, reviews, etc. Then spend a bit of time reporting the offending pages as spam

Hope that helps?

Paul

Your dev is right on the specific question of whether the additional GMB profiles are necessary for Google to understand which is the primary version. This is not essential as long as the proper redirects are in place. It's a "belt and suspenders" approach. If there's no way for the search engine crawlers to ever reach anythig but the primary version, then there's no way for them to get it wrong. You're using the GMB info to reinforce what the redirects are already doing. (That said - it's trivial to reinforce the redirect process with the declaration in GMB, so best practice is to do that as well. You need the GMB profile to properly manage the other aspects of marketing the site anyway, so...)

Put another way - declaring the primary version of the site using the alternate GMB profiles is Google's way of allowing those who might not have proper dev access to sites to at least partly accomplish the same thing from within GMB which they can manage.

The real value to verifying the other versions in GMB is so that you can monitor to make certain that those non-canonical versions of the site are in fact definitely not getting indexed or ranked. This is essential after an HTTPS migration, for example, as you should see the HTTP profile showing a steady drop in indexing while the HTTPS profile shows the steady increase.

A periodic check of the non-canonical GMB profiles will alert you immediately to any newly discovered issues Google's crawlers may be encountering (like a sitewide redirect got accidentally removed or changed, for example.)

Make sense?

Paul

I'm well aware of the reasons why small business owners might not want to have their home addresses listed, but it doesn't change the fact that Google will not allow use of UPS Store-type mailing addresses to pretend to be business locations. It's not a matter of having a "verifiable address" it's a matter of adhering to the requirement that you must have an actual business presence at that specific location where customers can come in person for service/sales.to qualify the local GMB address.

It is possible to set your home address, then select that it should be hidden and function as a local service area business instead.

But trying to get away with using a non-conforming "pretend" address will get you delisted when caught (and Google is very good at catching such non-conforming addresses in many ways, if it even lets you verify it in the first place.)

This is not just my opinion - it's specifically stated by Google in their own GMB terms of service. In fact, Local Search expert Miriam Ellis just posted about this in her Not-Actually-The-Best Local SEO Practices. To quote:

"Once caught, any effort that was put into ranking and building reputation around a fake-location listing is wasted."

Paul