Welcome to the Q&A Forum

Great reply from Tom. The other way to see it (more from philosophical nature) - by definition the 'world wide web' is

'The World Wide Web (www, W3) is an information system of interlinked hypertext documents that are accessed via the Internet and built on top of the Domain Name System'. (Wikipedia)

If you site only has only incoming links, and no outgoing links - it's like a dead end street (or and end-node) and would be a bit in contradiction of what the www is (was) all about. It would also seem that you are convinced that your site has all the possible answers / solutions for a certain topic and that you are convinced that no other site could be of interest for your visitors.

No hard facts or figures to support this theory, just my gut feeling.  If you have a number of good external references that have added value content for your visitors I would certainly link to them.

rgds,

Dirk

Hi Dustin,

If the site is the one mentioned in your profile - it's almost certain that it's a speed/performance issue. I checked one product page - and grade from google for desktop is 49/100 - 67/100 for mobile. Webpage test indicates the page size of 2700K - mainly images, javascript & flash. It should not be to difficult to improve these scores - optimising the images & the js will help a lot.

rgds,

Dirk

This can have different reasons - without having the actual example it's difficult to assess. Based on the info you give, adding all this content, video, images, it could be that your page became a lot heavier to load (check the page on webpagetest.org and with pagespeed insights). May be you exaggerated a bit with the optimisation - and is Google considering the page a bit too spammy.

If possible, can you give the actual url of the page?

rgds,

Dirk

Hi Rajiv,

If you post the same content on both FR & EN version:

• if both are written in English (or mainly written in English) - best option would be to have a canonical pointing to the EN version
  Example: https://fr.sitegeek.com/category/shared-hosting - most of the content is in English - so in this case I would point a canonical to the EN version

• if the FR version is in French - you can use the HREF lang tag - you can use this tool to generate them, check here for common mistakes and doublecheck the final result here.

Just some remarks:

• partially translated pages offer little value for users - so it's best to fully translate them or only refer to the EN version

• I have a strong impression that the EN version was machine translated to the FR version. (ex. French sites never use 'Maison' to link to the Homepage - they use Acceuil). Be aware that Google is perfectly capable to detect auto-translated pages and they consider it to be bad practice (check this video of Matt Cutts - starts at 1:50). So you might want to invest in proper translation or proofreading by a native French speaker.

rgds

Dirk

Hi Justin,

It depends a bit on where these links are & on how your site is build.

In general - if these links are in the navigation, footer, ...etc (elements which are called on each page) - you probably only need to change them once and then it is ok for the full site.

If these links are inside articles, you will probably have to update them manually. It sometimes is possible to do something like 'find/replace' - so you could replace (as example) all references from zenory.com to zenory.co.nz (for the NZ version) - but again it depends a bit on the platform.

Check with the one who has build your website - changing links manually can be a very annoying & time consuming job (depending on the number of links that need to be changed). A programmer can sometimes find a solution to automate part of it.

rgds,

Dirk

Hi Justin,

If the same page exists as well on the .com version (which seems to be the case) I would replace the .co.nz version by the .com version.

In Screaming Frog under Bulk Export you can export all the outgoing links. This will give you both the pages with outgoing links & the pages where they are linking to. Open in xls - and filter the destination pages on links that contain .co.nz or .com.au (when you are checking the .com version). This will give you all the source pages which need to be updated.

rgds

Dirk

Jennifer,

Some of your pages still reference http images - example https://www.tsheets.com/proadvisors-we-trust.php calls image http://cdn.tsheets.com/images/pros/denise-loter-koch.png

"Your connection to www.tsheets.com is encrypted with obsolete cryptography. However, this page includes other resources which are not secure. These resources can be viewed by others while in transit, and can be modified by an attacker to change the look of the page."

This is probably the reason for the 804 errors in Moz.

You should also check your internal links - some of them still point to the http version which is then again redirected to the https version

Example https://www.tsheets.com/infographics/time-tracking-infographic-hr-industry links to http://www.tsheets.com/infographics/time-tracking-infographic which is then redirected to https.

Unrelated to the https - but you might want to optimise the image on https://www.tsheets.com/online-invoicing-and-billing/ (https://www.tsheets.com/online-invoicing-and-billing/images/main-image-billing.png)

rgds

Dirk

Hi Ana,

Just to clarify - if you redirect based on ip to a location based url like /newyork you can still have a link on the page going to the other locations like /sandiego - so Google can access all these pages & index them. This is not possible it the scenario you mentioned.

Not sure how old the article from unbounce is, but Google bot is able to interpret javascript (to a certain extent). Using javascript won't change the problem - as long as you have only one page that adapts automatically to the ip location you will be unable show all versions of the page to Google - it will help your Californian branch, but hurt all the others.

rgds,

Dirk

Hi,

I fear that it's not going to work for the Arabic version. In each case I am certain that the on page grader of Moz is unable to deal with non-latin characters - see also the answer from Matt Roney on this question: http://moz.com/community/q/use-of-moz-with-non-latin-characters

rgds,

Dirk

Hi Justin,

It's quite common to have links between different versions of site if they are targeting different countries. It could also be considered good for the user experience to offer the user the choice to choose the site which corresponds to his country.

You just have to make sure that the links between these different versions are voluntary not accidental links. If a user is browsing your site and suddenly switches from to the .com to the .co.nz because the internal links on your site are not properly configured this could be considered as bad practice.

As usual - Screaming Frog is your best friend for this. Crawl the sites, check the pages with outgoing links to the other versions. If the link is accidental - correct it.

Hope this helps,

Dirk

Hi,

You could check this tool http://flang.dejanseo.com.au/ to check if the tags are properly implemented.

rgds,

Dirk

The easiest way would be to put the robots.txt in the root of your subdomain & block access for search engines

User-agent: Googlebot
Disallow: /

If you subdomain & the main domain are sharing the same root - this option is not possible. In that case, rather than working with robots.txt I would add a canonical on each page pointing to the main domain, or block all pages in the header (if this is technically possible)

You could also check these similar questions: http://moz.com/community/q/block-an-entire-subdomain-with-robots-txt and http://moz.com/community/q/blocking-subdomain-from-google-crawl-and-index - but the answers given are the same as the options above.

Apart from the technical question, qiven the fact that only the labels are translated, these pages make little sense for human users. It would probably make more sense to link to the normal (English) version of the blog (and put (en Anglais) next to the link.

rgds,

Dirk

Hi,

It seems that they are having technical issues - as mentioned by Rand last week on this question http://moz.com/community/q/when-is-ose-updated

"Our index is taking much longer to run than expected. We think there may be a hardware or software issues in processing that's having problems. We'll be doing maintenance so we can get back to faster indices ASAP."

We'll just have to be patient I guess,

Dirk

Hi,

When you say that referral traffic was unaffected - did you see the burst of traffic in Analytics or not?

In webmaster tools - do you see that clicks go down to zero during this timeframe. Was there an increased number of crawl errors during this period?

Was your site able to handle the traffic or did it go down - sometimes when sites are unstable or frequently offline Google temporary removes them from the SERP's until the situation has normalised.

Without additional info it's difficult to judge what exactly could be the cause. I never heard that a sudden peak of traffic from one source had an impact (in the negative sense) on search traffic - normally more visits from other sources are rather positive for your rankings.

rgds,

Dirk

Hi Jennifer,

Migration to https has certain risks (like any other migration of your site). Without the actual url it's difficult to asses what's wrong with the site.

1. You can check here if the SSL was properly implemented: https://www.ssllabs.com/ssltest/

2. There is an interesting article on the technical migration on the site of Yoast (https://yoast.com/move-website-https-ssl/) - and about the potential SEO impacts here: http://moz.com/blog/seo-tips-https-ssl - even if you have already migrated you could check the different steps & check if you have skipped one.

3. Try crawling the site with Screaming Frog - it has a tab Protocol that can show you if all pages are on https or if some are missing. You can also check if all your internal links are updated to the https version.

4. I guess you have created a WMT for https version of your site - check if specific errors are listed.

5. Check pagespeed with google page speed analyser & webpagetest.org - check your scores. It possible that adding the https also made your site slower.

6. Sample pages in different browsers - do you get security warnings when visiting pages. These messages can really frighten your visitors, and have impact on stats like bounce rate & avg. visit duration, and as result have an impact on your rankings

7. Check vital stats in Analytics - like bounce rate, pages/visit, avg visit duration, avg time on page... - did you see major changes after migration. Also check if you see an increase in 404 pages.

Hope this helps in solving your problem,

Dirk

Did you seem a similar drop in Webmaster tools?

When I see such a sudden drop & fast recovery my first guess would be that something went wrong with your analytics tag. How was you overall traffic during this period? Did you see the Facebook traffic appearing in referrals?

Apart from the Facebook push - did you do technical changes to your site in the same timeframe?

rgds,

Dirk

Hi Patrick,

If the question would have been about country targeting I guess your answer would have been correct. As mentioned in the article however, the lowest level of geolocation is country. As the question was about locations "nationwide" I would conclude based on this article that at this point of time Google is unable to detect geo-targeted content based on region or city.

Even for countries I think it's a risky business - as the article doesn't indicate if this "local" bots visit the sites with the same frequency & depth as the normal ones, and they don't clearly indicate which country ip's are used.

It's a different story for languages - because you can indicate in the HTTP header that the content is depending on the user's language. A similar case is the dynamic serving for mobile (https://developers.google.com/webmasters/mobile-sites/mobile-seo/configurations/dynamic-serving?hl=en) - here you can indicate that the content is changing based on the user agent.

As far as I know, there is no way to indicate in the HTTP header that the content is varying based on ip address.

rgds,

Dirk

Hi,

I don't really agree with the answer of Patrick. Depending on the level of personalisation you apply, it can hurt your rankings for locations outside California (our eventual other ip locations for Google bot).

As an example - you manage a chain of Chinese restaurants spread around the country and you have the domain mychineserestaurant.com.

If users accesses the site directly in New York, he will see the address, picture, phone number etc. from the New York restaurant. Googlebot however will never see this content - the bot will only be able to access the content from your branch in Los Angeles. While this is great for the user experience, there is no way to show Google the other locations, as you are obliged to show the bot the same content as normal human users, and hence show the information based on the ip of the bot.

The example of Groupon given by Patrick is not exactly the same - they personalise the homepage based on your ip - but if you search for Groupon New York you go to http://www.groupon.com/local/new-york-city

What you could do is automatically redirect the user to the appropriate page based on ip - but still have the other pages accessible via normal links. In the example above - accessing the site in New York I would go by default to mychineserestaurant.com/newyork but with the option to change the location. This way Google bot would be able to crawl all the locations. It's also the advice coming from Matt Cutts: https://www.mattcutts.com/blog/give-each-store-a-url/

If the personalisation is only minor (example only the local address on the homepage) and if you already have targeted pages for each location it should not really be a problem.

To be honest - it's rather my own opinion than something which is supported by hard facts.

Hope this helps,

Dirk

Hi Alick,

You might find this article useful: http://moz.com/blog/how-to-stop-spam-bots-from-ruining-your-analytics-referral-data - the two options that are listed is blocking bot traffic using htaccess - or filter them in Analytics. If you check the link I gave you in my first answer - there are also some useful resources listed. Other resources can be found here: http://moz.com/community/q/google-analytics-referral-spam (and off course - just google "referral spam" - it's quite a popular subject)

Hope this helps

Dirk

Hi,

It's quite possible that it's just a matter of time before the label shows like Patricks mentions. However, if you check your site with PageSpeed Insights there seems to be something strange with the way you implement the redirect: https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fwww.pssl.com which could be the reason why the label does not appear:

Your page has 2 redirects. Redirects introduce additional delays before the page can be loaded.Avoid landing page redirects for the following chain of redirected URLs.

• http://www.pssl.com/
• http://www.pssl.com/!XkggQFlbOgq2yNN3W1icyA!/
• http://m.pssl.com/

If you want to check this "manually" you can check the headers yourself using web-sniffer.net with a mobile user agent. I would check with your technical team how to avoid this redirect chain.Apart from that, if you check the insights for speed, your scores for both mobile & desktop are not really great. Testing on webpage test  http://www.webpagetest.org/result/150429_62_19PT/1/details/ - loaded in 3.7 sec is not extremely bad but not great either. You could probably reduce the load time by combining your 19 js & 6 css files. For mobile 400K images & 270K javascript (!) is probably a bit too much to load over a mobile connection(the test also shows the double redirect).rgds,Dirk