Welcome to the Q&A Forum

Google's generally pretty good at recognising this kind of hot-linked image use by spammy sites is not intended to be manipulative by the site owner.

The most direct solution, both to be safe and to keep other sites from abusing your bandwidth/server resources is to block hot-linking of images like this altogether. Is there any legit situation where you need to allow other sites to embed your images? If not, a blocking rule in htaccess will break all those existing spam links (easier than disavowing) and stop cold any new ones from being automatically created.

Would that work in your situation?

Paul

No, well-presented, user-friendly popups like exit-intent popups won't have anything to do with the ad blocking that's going to happen.

You'll probably find Xenu Link Sleuth will work for this, Red. Not quite as elegant as using an extraction in Screaming Frog, but it is free.

Lemme know if that works?

Paul

There is rewrite code to do that in one "hop". But the best practice for this has changed from what the pagespeed tools recommend, Fitz. You should actually leave the redirect as is, and insure you have HSTS properly implemented for the website. For HSTS to work properly/securely, the site must redirect to the HTTPS version of the same hostname before then redirecting to the canonical hostname. Which is exactly what your site is doing.

The only disadvantage to the extra hop is that there's a very small delay for an additional server calll, but the implementation of HSTS eliminates a server call and some certificate negotiation time. So breaks about even or even a little quicker, especially if you submit to the Preload list once you're certain HSTS is working correctly. Note that HSTS should be implemented using a very short TTL initially so you can be sure things are working correctly before switching to a long TTL and the preload list.

Do you already have HSTS configured for the site??

Paul

I'm surprised to say... that SSL certificate you have is very poor quality and has a number of pretty significant security issues, in addition to the SHA-1 encryption.]

To answer your specific question, there's nothing you or your devs can do about the SHA-1 encryption problem, as that problem exists on one of the certificates in the chain that is owned and controlled by Thawte (the cert issuer or "Certificate Authority"), not your own certificate. It is up to them to fix it.

As you can see from the cert security scan, there are a number of other issues with the certificate that are unacceptable. Especially in a paid certificate. [Edited for clarity - some of those warnings are likely server-specific, meaning the server is being allowed to communicate with certificate in less than optimal ways]
https://www.ssllabs.com/ssltest/analyze.html?d=www.key.co.uk

It's unlikely that the encryption problem is whats giving the "not secure" warning on the site at the moment (although it will become a major issue later in February) so you'll  need to keep looking for resources called over HTTP if you're still getting warnings.

When I had a quick look at the home page, I didn't see any more warnings, as it appears you've fixed the image call that Andrew mentioned. You can use Chrome or Firefox Dev Tools to inspect any pages that are not secure to be shown exactly what element is causing the failure. It often comes down to hardcoded images like those in CSS/background images etc, or hardcoded scripts. For example, your Quotations page is calling a script from Microsoft to validate the form, but it's failing as it's called over HTTP.

Knowing this, you'd want to check any other pages using such form validation. A thorough Screaming Frog crawl to look for any other wayward HTTP calls can also help dig our the remaining random culprits.

Hope that helps?

Paul

Sidenote: Your certificate authority is Thawte, which is connected with Symantec. Which has done such a bad job of securing their certificates that Chrome and other browsers no longer trust them and are in the near future are going to be officially distrusted and ignored. Symantec has in fact given up their Certificate Authority status and is transferring their business to a new company which does have a trusted infrastructure for issuing certificates. So you're going to need to deal with a new certificate in the not too distant future anyway.

Given the poor security of your existing cert, and the upcoming issues, if it were me, I'd be asking for a refund of my current cert, and replacing it with one from a more reliable issuer. I know that can mean a lot of extra work, but as these existing problematic certs go through the distrust process over the next 8 months, sites that haven't dealt with the issue are going to break.

It's possible that Thawte will build out a reliable process for migrating. At the very least, you need to have a strong conversation with your issuer about how to insure you are getting the security and long-term reliability you've paid for. Sorry to be the bearer of bad news that is a much bigger issue. You can read up about it more here:
https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html

Agree with EGOL - very common procedure.

The one functional consideration you must take into account though is that each site should be hosted in a separate account on the server so malware or hacks from one cannot contaminate the others. That's also best if individual clients will need hosting access to their own sites - otherwise, it can be difficult to keep clients away from the back-end of each others' sites.

Paul

My experience is similar to EGOL's. A carefully-implemented domain migration usually settles out within two or three weeks. There will still be some hiccups in certain terms etc for an additional couple of weeks, but those are usually in an upward direction as the new site is an improvement over the old.

If it's been two months and you haven't' yet at least returned to previous levels, it's time to get going on a thorough audit to figure out why and correct.

Tough spot to be in as someone who wasn't involved in the original build, but it does give you the benefit of fresh eyes. The key is to question everything - don't take anyone's assurance about what was done in the migration. Prove each item for yourself before accepting that it's been done properly.

Good luck!

Paul

That Moz help page is kinda half-right For many browsers, in the absence of a title attribute, they will display the alt text on hover instead. But if a title attribute is declared, it will be used, as you note.

Keep in mind - image title attributes are not used as ranking factors for regular search, but they are used as ranking factors for Google Image Search. So still well worth optimising them if your site benefits from image search specifically (as a good photographer's site likely would).

Paul

That was quick - good job!

P.

The regex in your RedirectMatch doesn't say what you think it says, Jes

This part (note the bolded part of the expression (.*)

/category/Sample-Category**(.*)**

doesn't actually say "match the URL that is specifically** /category/Sample-Category"**

That**.*** is a wildcard thatmeans "and any other additional characters that might occur here"

So what it's saying is "match the URL /category/Sample-Category _**as well as **_any URLs that have any additional characters after the letter "y" in category. Which is what is catching your -1 variation of the URL (or the -size-30 in your second example).

In addition, that wildcard has been set as a variable (the fact it's in brackets), which you are then attempting to insert into the end of the new URL (with the $1), which I don't think is your intent.

Instead, try:

RedirectMatch 301 /category/Sample-Category https://OurDomain.com.au/New-Page/

you should get the redirect you're looking for, and not have it interfere with the other ones you wish to write.

Let me know if that solves the issue? Or if I've misunderstood why you were trying to include the wildcard variable?

Paul

P.S. You'll need to be very specific whether the origin or target URLs use trailing slashes - I just replicated the examples you provided.

Nice catch & very likely the problem.

Great! Happy to help. And yea, do let us know how the adjustments work out.

And thank you for the wonderful wishes - very much appreciated. Wishing you a rewarding 2018 too!

Paul

Your robots.txt is actually the issue in this case, Sainath. (The giveaway is that No information is available for this page text, which is the standard response on Google for a page that is blocked by robots.txt.)

The problem is that your robots.txt is blocking all URLs that contain UTM parameters . Since the shortened URL is redirecting to a site page URL which contains UTM parameters (https://in.musafir.com/Visa/Singapore-Visa.aspx?utm_source=youtube&utm_medium=youtube_channel&utm_campaign=Singapore_visa_video) and is therefore blocked from crawling, Google can't properly crawl/discover the actual destination page and its real URL and meta-description via this link, so it continues to return the only info it has available - the shortened URL and the blocked-description warning.

Your site is already protected from issues with UTM parameter URLs because it has properly implemented self-referential canonical tags, which is the correct way to deal with them. You should remove the robots.txt blocks for all those parameters (especially including the gclid - I suspect that's causing issues with our Adwords Quality Score). This way, the search engine will be able to properly understand each stage of the redirect you've created and index the proper URL and meta-description

In short - those parameter blocks in your robots.txt file are causing multiple issues for your site, without doing anything beneficial.

Does that make sense?

Paul

I'm afraid we're in a bit of a state of limbo on this issue, Nickington.

Currently, Google's ranking is based on the desktop version of the site for both desktop and mobile results.

Google has clearly stated, and many tests have confirmed, that content which is not visible unless a user interacts with the page (such as having to click the drop-down for the FAQ result) is deemphasized in search results.

BUT! Google has also stated that they are in the midst of changing to a mobile-first index which will mean that the mobile version of websites will be used for ranking assessment. In addition, they've been quite clear that at that point, since things like accordion drop-downs are so much better UX for mobile users, that kind of hidden content will no longer be "penalised".

Unfortunately, there's been no declared date for when the switch to the mobile Index will occur. Instead, they've said that it will be rolled out gradually to individual sites as they detect that the mobile version of a site is ready for it. This means it's entirely impossible to assess when the changeover might apply to your site.

So for absolute best SEO, the solution is unfortunately a bunch of extra work for a hybrid solution My best recommendation would be to build out the FAQ content using headers and sub-headers so the content is fully visible on the page and gets full indexing authority from the search engine. Then keep an eye on the mobile indexing of your site to detect when it appears that it has moved fully into the mobile-first Index stage, and at that point redo the FAQ page to utilize the accordion drop downs instead.

The alternative would be to build out the page using the accordion drop downs to start with, and accept the fact that it will be some time before that hidden content has a chance to rank effectively. this would definitely be a second-best option in my opinion.

Does that all make sense?

Paul

Nope, no effect, as you suspect, Eddie. That kind of attempt at copy-blocking doesn't change the way the content is available in the DOM of the page (which is why it's so ineffective) so has no effect on crawling/indexing.

You can prove this for yourself by going to a page and right-clicking to select the browser Inspect mode. This mode shows the actual rendered DOM of the page that the search engines are reading, and you'll see the content is easily accessible. The other option is to do a Fetch and Render request from within the site's Google Search Console and it will also show you what content Google can see.

That what you were looking for?

Paul

The WP migration plugins I'm referring to do a rewrite of the URLs in the database. And yes, this is critical to a solid migration, instead of using redirects. There are a number of WP tools for this. My preferred tool is BackupBuddy (paid- 40% off this month) as it does an excellent job of the migration and is then a top-notch tool for managing the ongoing backing up of the site, as well as helping create a staging version of the site for future dev and maintenance purposes. I've also used the free Duplicator plugin for one-off migrations, and have used Updraft Plus on occasion as well.

The majority of the work is in tuning up the site after migration, and yes, making sure all the related functionality and tools have been updated as well.

My timeline would look something like this:

• Create addon domain in hosting cPanel for new domain and enable AutoSSL certificate - 15 mins
• Use migration plugin to move site to new domain - 1 to 1.5 hours depending on experience
• Run quality Assurance testing to insure all of site and functionality is running properly under new domain and HTTPS, including updating CDN and testing forms - 1-2 hours.
• Review and update 3rd party tools and off-site profiles - 2 hrs
• Implement final DNS changes and redirection of old domain to new, add change of address in Google Search Console - .5 hr
• Miscellaneous, including setting up backup protocol for new domain - 1 hr
• (And don't forget 3-4 hours of careful monitoring and followup for any errors over the following 4-6 weeks after migration, plus earning of new links to the new domain, and getting existing links replaced with new ones to the new domain where possible.)

For a total of about 6 or 7 hours for the migration work itself.

You're right, a clearly laid out and well-priortised project plan for this kind of migration is absolutely essential. You need to know exactly what's going to be done, and in what order, so you can insure all necessary steps are taken. To be blunt, many devs (even really good ones) don't take into account the extra details necessary in migrations like these that an experienced SEO pays attention to.

Having all the images on Amazon CDN actually simplifies the migration somewhat as those images will not have to be moved during the changeover, just have the CDN adjusted instead. The SSL should absolutely be installed on the new domain before migration - otherwise, you are going to add a lot of wasted time and complexity rewriting the database URLs a second time after the domain name change to update them to HTTPS.

Paul

No question - the page's authority is divided up amongst all links on the page, not just the internal ones. That's why I made the recommendation I did.

To be clear - you're not "losing Pagerank" for the page that contains the links. You're losing the ability of that page to pass some of it's power to other pages on your own site, by having that power sent to external sites instead.

Paul

That's not going to solve your problem, vikasnwu. Your immediate issue is that you have URLs in the index that are HTTPS and will cause searchers who click on them not to reach your site due to the security error warnings. The only way to fix that quickly is to get the SSL certificate and redirect to HTTP in place.

You've sent the search engines a number of very conflicting signals. Waiting while they try to work out what URLs they're supposed to use and then waiting while they reindex them is likely to cause significant traffic issues and ongoing ranking harm before the SEs figure it out for themselves. The whole point of what I recommended is it doesn't depend on the SEs figuring anything out - you will have provided directives that force them to do what you need.

Paul

Yup, but doesn't matter. Hreflang works for this situation whether cross-domain or on a subdirectory/subdomain basis (and in fact is even more effective when cross-domain as you're also getting the benefit of the geo-located ccTLD.)

P.

Unfortunately, your information is incorrect, Veronica.

Hreflang is specifically designed for exactly this situation. As Google Engineer Maile Oye clearly states, one of the primary uses of hreflang markup is:

• Your content has small regional variations with** similar content in a single language**. For example, you might have English-language content targeted to the US, GB, and Ireland.
  (https://support.google.com/webmasters/answer/189077?hl=en)

There's no question differentiating similar content in the same language for different regions/countries is more of a challenge than for totally different languages, but it can absolutely be done, and in fact is a very common requirement for tens of thousands of companies.

Paul