Welcome to the Q&A Forum

Yup - Google still says content that can only be seen after a user interaction is given less importance. Kinda stupid, given that things like tabs/accordians are a major usability enhancement, but that's still where we are.

P.

Targeting the same keywords with an additional site could certainly affect impact your existing rankings. You'll essentially be competing against yourself. But it won't make any difference whether the second site is on an addon domain in your primary hosting or on a different host/IP address. Google has so many ways of knowing that two sites are related that goes far beyond what IP they use.

There can be instances where a second site for the same topics can be necessary/effective, but you'll want to be really sure that's the best approach as opposed to adjusting your existing site to accommodate whatever it is you're trying to accomplish. You're literally doubling your workload and competing against yourself in the process.

What's the purpose of the second site? To go after a completely different market segment?

Paul

You may be overthinking this, Becky. Once the bot has crawled a page, there's no reason (or benefit to you) for it to crawl the page again unless its content has changed. The usual way for it to detect this is through your xml sitemap,. If it's properly coded, it will have a  <lastmod>date for Googlebot to reference.

Googlebot does continue to recrawl pages it already knows about "just in case", but your biggest focus should be on ensuring that your most recently added content is crawled quickly upon publishing. This is where making sure your sitemap is updating quickly and accurately, making sure it is pinging search engines on update, and making sure you have links from solid existing pages to the new content will help. If you have blog content many folks don't know that you can submit the blog's RSS feed as an additional sitemap! That's one of the quickest ways to get it noticed.

The other thing you can do to assist the crawling effectiveness is to make certain you're not forcing the crawler to waste its time crawling superfluous, duplicate, thin, or otherwise useless URLs.</lastmod>

Hope that helps?

Paul

Knowing that with a large body of documentation like this, the chances of being able to rewrite it all to combine into a single page are pretty slim (and knowing that might be a very negative user experience) you're really only left with the canonical tag option - assuming the older docs need to be maintained.

You're right to be concerned, as Google has been clear that canonical only applies to pages that have substantially identical content. Unfortunately, they do a really poor job of explaining just how much variation would be allowed.

Is it okay if the canonical is not an exact duplicate of the content?
We allow slight differences, e.g., in the sort order of a table of products. We also recognize that we may crawl the canonical and the duplicate pages at different points in time, so we may occasionally see different versions of your content. All of that is okay with us.
~ https://webmasters.googleblog.com/2009/02/specify-your-canonical.html

My impression is that they would honour canonical in your use case.

Really, the only way to know is to select a couple of products' documentation pages and conduct a test. Canonicalise all old version to the current version and request re-indexing for each page. Then monitor the results (The new index monitoring tools in the new GSC are useful for this). You'll want to choose at least one test case that involves featured snippets - it would be incredibly useful to know if the FS transfers across to the new canonical page!

Do note that you'll need an ongoing process for managing the canonicals s each new iteration of documentation is added - all related pages will need to have their canonicals updated to point to the newest each time new docs are published.

Interesting conundrum. Please let us know the results if you decide to try a test!

Is that useful?

Paul

Google has said that when they find the same page under both HTTP and HTTPS, they will try to return the HTTPS page in search (certain circumstances ap[ply). But the fact remains that you are making the search engines "figure it out" instead of giving explicit directives that ensure the correct behaviour.

I suspect the HTTPS split has already done its damage, especially with regards to backlinks now pointing at two destinations and thus splitting the authority. Which is likely the cause for your suspicion of the underperforming backlink profile.

So the process of getting the HTTP dupe resolved to HTTPS with the redirect should start delivering improvement as soon as the new crawling/indexing gets done. I strongly suspect this improvement will offset most if not all of the effect of the new HTTPS redirects.

There's no way to estimate the effect of the addition of the proper HTTPS redirect, but given that you're already in a compromised hybrid state, my strong suspicion is that it will actually improve the situation without much temporary drop at all. In essence, you've already experienced the negative pressure. The changes will serve to start to reduce the negative pressure immediately.

But this is my best assumptions. I haven't done an HTTPS redirect correction on such a large site. On the smaller sites I've fixed though, the uptick happened within a week or two. Though not dramatic improvements still beneficial.

The other thing to be aware of: Google has stated that when they do the reindexing to HTTPS, it's essentially like recrawling a new site. So they apply all the tests and quality checks to all pages. So if you have existing issues to clean up, do that before final implementation of the HTTPS redirect.

I'd be really interested to follow your results on this - sounds like a solid opportunity for a case study!

Hope that helps;

Paul

Google's been quite clear that reviews on our sites from 3rd party review sources must not have review markup, SK. It's grounds for a "manipulative markup" penalty.

Review markup should "Only include critic reviews that have been directly produced by your site, not reviews from third-party sites or syndicated reviews."

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

Removing them from the Console will have no effect on your  site, Ruben - its' purely for your own housekeeping purposes.

Mark them fixed to get them out of the lists so that real ones will be easier to spot as they come up. As long as the spam links are landing on a real hard 404, they will eventually drop out. But it will take a considerably long time because those spam pages are such low value that Google isn't likely to recrawl them to discover the 404 very often. (Not that that will do you any harm, just annoying to look at.)

Also - don't be alarmed if some of those you mark "fixed" show up back in the list in a couple of months - that's not indicative of any problem.

Hope that helps?

Paul

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

Adding Google Analytics to your SEOMoz reports is just a nice add-on. Not implementing it will have not effect on your SEOMoz reports, it just means the Analytics data can't be automatically included.

It is pretty tough to do good SEO without a strong analytics foundation for your site though, which is one of the big drawbacks to a WordPress.com site, especially for business. In addition, you can't install any of the SEO plugins that allow for the kinds of customizations you may want/need.

But short answer - no, not being able to add Google Analytics will have no effect on THE SEOMoz tool itself.

Hope that helps?

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

Just one quick thing, Vikash. i fully understand that you're just diving into this area, but I want to warn you that if you start with a hosted WordPress.com site and eventually build up business value in it, it's actually a huge amount of work to transfer the business value of that site to a self hosted version of WordPress in the future.

If this site is a serious start towards building an online business presence, I would strongly recommend you seriously consider doing it on a self-hosted version of WordPress instead. It will save you a massive amount of work down the line. It will also give you significantly more flexibility in the near term as you start optimizing your business site.

On the other hand, if the site is just an experiment for when you will build your next real site, WordPress.com is a reasonable place to start.

I've just encountered far too many people who started a business site on WordPress.com, only to later find they practically had to restart from scratch when it's limitations became too great for their business.

Just something to think about.

Paul

The example page does have a noindex tag in place, but it's not formatted correctly, so it's being ignored. Very subtle issue, but your tag is using "smart quotes" around the elements instead of the plain quotation marks that are required for code. If you look very carefully at the page source code, you'll see that they are quotation marks like you'd see in a Word document; the ones at the beginning of robots and noindex curl a different way than the ones at the end.) This usually occurs when the content was written in a word processor instead of a plain-text editor.

Because the tag's not formatted correctly, it's ignored by both the crawling tools and the search engines.

In addition, the site also has all pages blocked from crawling by the sitewide robots.txt file. This and noindex are conflicting instructions to search engines.

If a page is blocked in robots.txt, then the search engine will not crawl the page and so is not able to discover the noindex tag, even if it were formatted correctly. Therefore if the search engine becomes aware of the page in any other way than straight crawling (and there are a number of ways this can happen), then the page will still get indexed.

If it's a dev site, the proper way to keep it from being indexed is to either noindex all pages, or to put the site behind a password so the search engines and public visitors can't access it. If using noindex, the site must not be blocked with a robots.txt directive.

Does that all make sense?

Paul

The other conference I would suggest is worth considering is SMX Advanced. Unfortunately it's west coast also (Seattle in June) but depending on your level of expertise, it's a terrific conference. It shares the good aspects others have mentioned about SMX West etc, but the presentations are at an even higher expertise level.

Not hard to come out of the sessions with your head swimming with new stuff, even if you've got lots of background. If you're thinking of attending and need to minimize accommodation costs, lemme know. I can recommend the terrific pensione I stay at that's less than a 10-minute walk.

I will say too - if you're looking for ways to take your practice to the next level, a conference is a really good next step. In addition to whatever new skills/info you pick up, the time to be immersed with so many others who "get" what you do without needing a long explanation is wonderful! Those new connections can often be critical to our further development as well.

Paul

P.S. If you're looking specifically for east coast events, check out the Distilled SearchLove conference in Boston. I've never attended but they're a terrific company and I've heard good things about the conference. It's in May http://www.distilled.net/events/searchlove-boston/ (I've got a ping out to my east coast SEO connections - met at last SMXAdvanced actually - and will update if I get more suggestions.

<object id="plugin0" style="position: absolute; z-index: 1000;" width="0" height="0" type="application/x-dgnria"><param name="tabId" value="ff-tab-97"> <param name="counter" value="320"></object>

I can really strongly recommend "Optimize" by Lee Odden. It focuses on the integration of SEO, Social Media and content marketing when creating a web marketing strategy. Personally, I feel this integrated approach is the only way to go for modern web marketing.

You say you're "more of an SEO person", Taysir, but you do say you're interested in developing great online marketing strategies. If that's the case, you're going to need to get beyond just SEO pretty quickly, as it's just one tactic in a true online strategy.

There are a huge number of excellent books on each of the tactics that make up a good strategy, but I recommend this one as a strong introduction to the process of understanding the individual tactics and how they blend into a broader strategic approach to getting more business on the web.

Paul

Whatever you do, don't add the videos to a subdomain, Ubique. (e.g. new-section.mysite.com) You definitely want them in a subdirectory of the main site (www.mysite.com/new-section)

There are two extraordinarily good posts here on SEOMoz on how to plan and implement exactly what you're thinking of doing. Both are by Phil Nottingham, one of the better respected video SEO specialist out there.

Here's the post on planning a video strategy.

Here's his guide to video hosting and embedding. He specifically addresses your question about Vimeo vs YouTube vs cloud.

Those'll give you a full night's reading to get your head around

That the kind of info you were looking for?

Paul

Turning this question around, Danny, I'm willing to bet that your "old" site had its Analytics code incorrectly implemented and that it had been falsely reporting it's bounce rate all along.

In over 12 years of web marketing, I've never come across a regular site that had an accurate bounce rate below 10%.

The most common cause of such an unnaturally low bounce rate is having the Analytics tracking called more than once once on the page. This makes it nearly impossible for a visit to be tracked as bounce. This can also be caused by a number of other things (setting virtual pageviews to default pages actions etc) but dupe Analytics code is by FAR the most common.

Unfortunately I can't find a usable version of your site in the Wayback machine to try to check the old site. If you have an archived version of the old site, it would be well worth checking a significant number of its pages to look for dupe Analytics code.

I'd love for you to be the exception to my ultra-low-bounce-rate experience, but I'd seriously look at confirming that the old site's rate was accurate before assuming the new site has a new problem.

A 74% bounce rate isn't all that unusual for such a commercial site, though definitely a target for some of the improvements EGOL suggests.

In my experience - a bit of the former and lots of the latter. i.e. the specific page generates strong authority signals and as a result the parent domain gets credit for some of that extra authority as well. How much? No idea how to measure and I suspect the amount will be different under different circumstances. (This assumes the page is actually on the primary domain and not a subdomain).

I think of it like links: a strong incoming link to an internal page is especially good for that page, but also contributes to the overall site's ranking signals as well.

I'd be very interested to hear what others think on this topic too!

Paul

Looks to me like the Analytics was being called both within the Moonfruit system for Flash (around line 14) and pagetracker and _trackpageview were being called in straight javascript calls around line 222.  That'd definitely mess things up.

Little usability note - the links that are shown in your home page's slider are 404ing. Your 404 page would benefit from having a search box on it as well (as might the other pages on your site.) Unfortunately, WordPress's default search is HORRIBLE so you'll likely want to implement an alternative. There are a number of good search plugins available.

Paul

Quick reality check here, Brad. Your home page has over 180 links. So each of these social media links you're wondering about is passing 1/180 of the PR juice of the home page. I certainly wouldn't be fussing about this either way. Far bigger challenges to be focusing on.

That said, I certainly wouldn't be risking compromising user experience and user expectations in order to conserve 1/180 of a page's value. I'm not saying you're doing that - I think in some circumstances a dedicated social media page can be great. But as always - make the best decision for your users, not the search engines, especially in this case.

And to reinforce what Adam said - no-following links in NO WAY conserves page rank - that hasn't been the case for well over a year. No-follow has very specific purposes - to denote a link that you don't trust (e.g. from user-generated content like comments) or when the link is a result of a commercial relationship with the target site. The third use , which might apply to a few of your home page links, is to tell  the crawlers not to follow links to pages that are of no value to users other than being purely transactional - like your View Cart, Checkout, Create Account, Track Package etc.

The reason to no-follow these isn't to "save Pagerank" but to help conserve crawl budget so the crawlers can spend their time indexing more important pages.

Hope that helps?

Paul

P.S. If I were looking to conserve and transfer front page influence more effectively, I'd be seriously looking at reducing the sheer number of links on the page so the links that remain can transfer more value to the most important pages/sections of the site. Not going to be easy while maintaining usability, but that's where i"d be focusing my attention.