Welcome to the Q&A Forum

In that case it's indeed better to keep the country specific language version

Hi

The way you want to implement seems to be correct - not sure however if I would add the country to the language (although most Swedish people live in Sweden - you might want to attract all the Swedish speakers to the swedish version of your site rather than the en version) - so I would rather use hreflang="se"

If you implement it - you can always try and check a few url's to see if it's ok using this tool

rgds,

Dirk

Probably the easiest solution is to buy a licence from Screaming Frog & to crawl your site locally. The tool can do a lot of useful stuff to audit sites and will show you not only the full list of 4xx errors but also the pages that link to them.

There is also a free version but that allows you to crawl only 500 pages - which in your case is probably not sufficient but it would allow you to see how it works.

Hope this helps,

Dirk

Hi,

Not an encryption specialist - but maybe this question on stackexchange can help you solve the issue. According to one of the comments on the best answer (by  tlng05) - this could be done by modifying some server settings to allow clients to use at least one of the listed ciphersuites. In apache, this can be done in your VirtualHost configuration file. There is an SSL config generator you can use to make this easier: mozilla.github.io/server-side-tls/ssl-config-generator

Hope this helps,

Dirk

I just did a quick check on your site with Webpagetest.org with California IP address http://www.webpagetest.org/result/150907_G1_TE9/ - as you can see here these IP's also go to the holding page - which is logically the only page which can be indexed as it's the only one Googlebot can access.

rgds,

Dirk

Hi,

I can't access your site in Belgium - I guess you are redirecting your users based on ip address. If , like me, they are not located in your target country they are 302 redirected to https://www.woofadvisor.com/holding-page.php and there is only 1 page that is indexed.

Not sure which country you are actually targeting - but could it be that you're accidentally redirecting Google bot as well?

Check also this article from Google on ip based targeting.

rgds

Dirk

Hi,

You're quite right that having clean readable url's are usefull - both for visitors & bots.

There is no technical need to have these 'ugly' urls - as they can always be rewritten to something nicer. You will have to use a combination of URL rewriting & redirects) - you can find some useful links here on how to implement the rewriting (the article is not very recent - but these basics haven't changed). If they use a CMS it could also be useful to check the documentation - almost every decent CMS offers some build-in rewriting functionality.

The second issue with the strange domain name can be solved with a 301 redirect - by adding these lines in the .htaccess file of the "strange domain"

RewriteEngine On
RewriteCond %{HTTP_HOST} ^olddomain.com$ [OR]
RewriteCond %{HTTP_HOST} ^www.olddomain.com$
RewriteRule (.*)$ http://www.newdomain.com/$1 [R=301,L]

(no need to tell that you'll have to replace olddomain & newdomain by the actual domain names)

Apart from the wrong domain the issue with the tracking parameters in

http://website1-px.rtrk.com/?utm_source=ReachLocal&utm_medium=PPC&utm_campaign=AssetManagement&reference_id=15&publisher=yellowpages&placement=ypwebsitemip&action_target=listing_website

could be solved by either a redirect or a canonical url. With the redirect rule above the webwite-px.rtk.com will be redirected to www.yourdomain.com - but this doesn't get rid of the tracking code.

You could put a self referencing canonical url in the head of the pages -

or strip of the parameters using a redirect (you can find an example on how this could be done here

If you use the canonical solution - it could be a good idea to strip off the parameters in Google Analytics

Hope this helps,

Dirk

Hi Mary,

Maybe a temporary glitch in OSE? I just tried the domain in OSE & I get results without problems.

rgds,

Dirk

All the links are in javascript - and Mozbot doesn't crawl javascript (Google does however). Try visiting your site with javascript disabled - all you see is a blank page.

There is a similar question herethat may be can help you finding a solution - try also this post on AJAX & crawlability

Hope this helps

Dirk

Hi,

Could you clarify what you mean with "none of the images are indexed in Google Webmaster"? Did you submit an image sitemap?

If you do an image search - it seems that the correct images are found. Most important factors for image search is having

• correct Alt text (seems to be ok)
• a descriptive image name (could be improved - you use spaces in the filenames - would be better to use '-')
• you also provide a correct alt & title on the link to the bigger image so that look ok as well.
• you could add a caption to the image to make it even more obvious what the image is about.

A good guide on image optimisation can be found here

Hope this helps,

Dirk

Agree, coffee does make a difference. 3pm here in Europe so I already had my daily dose

Hi,

I don't really agree with the answer of Verbinteractive: disavowing links in WMT only concerns Google - there is no way Moz OSE is able to know that these links have been disavowed.

If these sites no longer exist than it's quite possible they will disappear in OSE, but not because of the disavow. If the links are from crappy sites it's quite possible that Moz crawled them once, but is not crawling them again (while the number of pages they crawl is huge - it's still limited).

Wait for the next crawl (Sept. 9th) & if these links are still present I would contact Moz directly.

rgds

Dirk

Hi,

I think performance might be the main issue for your site. Check the pagespeed insights for desktop & mobile - it took the server 3.7s (!) to react. The result on Webpagetest.org is even worse 12.5s time to first byte. As you can read in this article - time to first byte seem to have a correlation with the ranking of the site. Check if your server is properly configured & sized. With these load times it's quite possible that Google refuses to index your heaviest pages as they offer a degraded user performance. Another reason could be that  Google bot is not going to waste it's time waiting for your server to respond when crawling your pages.

There are some other quick wins here - compress your code, optimize images, use caching, combine css & js files, ... can all help to improve the overall performance of your pages - check these articles from Google.

A second issue is the duplicate content you have on the site - each page seems to exist in a http & https version - better to keep one & redirect the other one to the chosen version (I imagine you would want to redirect the http to the https version)

Hope this helps,

Dirk

Hi,

Not sure where you see the popup - it looks like a normal dropdown navigation (it's triggered by javascript but the links are in the HTML).

I would get over the concept of wasting link juice on internal links - it's absolutely normal (and even good for your visitors) to have pages like 'about us, contact us' and there is no need to hide these links using javascript or by putting nofollow's on them.

Check this article from Matt Cutts on linksculpting - a similar question can be found here - to quote the answer:

"No following those links (=hiding in your case) such as contact us does not mean that link juice is retained for the other pages you want to rank for. "

Hope this helps,

Dirk

Try to do a search of type viagra site:yourdomain.com - and see if there are any pages of suspicious nature that are listed.

In the crawl error section in webmaster tools you could also check where these url's are coming from (external/internal links)

If your site is hacked - you can find more info here http://www.google.com/webmasters/hacked/ on what to do next.

rgds,

Dirk

Hi

On first sight I would guess your site has been hacked - do these url's exist when you try them?

Dirk

It's probably possible to block these url's from indexing using a regular expression in your robots.txt - however keep in mind that if bots encounter these links users will encounter them as well which leads to a degraded user experience.

If I was in your situation I would try to solve the problem at the root - avoiding that these strange links are created in the first place.

rgds,

Dirk

Did  you validate both the www & the non-www version?

It could take some time before the links are taking into account. Apart from that, GWT is not exactly best in class to show the links to your site. This the reason why Open site explorer, Ahref,...etc exist.

Dirk

There are quite a lot of posts on Moz that cover link building. There is of course the beginner's guide, and this category page, which highlights the most important articles on link building.

Remember that all blogs once started from zero: without quality content, quality sites are not going to link to you. Create your content strategy and start building relationships. It will probably take time and a lot of effort, but it pays of in long run.

Hope this helps,

DIrk

Hi,

In the specific example you give it's doesn't really matter - as all the pages of the pagination have a canonical pointing to the homepage.

On top of that - the site indicates on every page that the alternate url for lang=es is the homepage as well.

If this is your site, I would correct this - make the canonical self referencing & do the same for the alternate url (or just drop the alternate url if the site is only available in Spanish)

To answer your question the link pointing to the next page is a plain html link: 2 so can be indexed by Google without major issues.

On endless scrolling & pagination with Ajax in general - there is an interesting article on Google Webmaster Central: http://googlewebmastercentral.blogspot.be/2014/02/infinite-scroll-search-friendly.html

rgds,

Dirk

Hi Kevin,

You will have to validate the https version as well - some background info: http://searchengineland.com/google-webmaster-tools-index-status-showing-data-https-protocol-187992 quote: "In order to see your data correctly, you will need to verify all existing variants of your site (www., non-www., HTTPS, subdirectories, subdomains) in Google Webmaster Tools"

rgds,

Dirk

Hi,

Can't find the link on the page you give as an example - but on other pages you have in the source a link of type

<a <span="" class="html-attribute-name">href</a><a <span="" class="html-attribute-name">="{link}"></a><a <span="" class="html-attribute-name">href="http://www.....dk/video-virtuelt-cockpit-i-ny-audi-a4/"</a>

<a <span="" class="html-attribute-name">Sourcepage: www......dk/bilmaerker/chevrolet/page/2/

In the browser the {link} is encoded as %7Blink%7D

Hope this helps,

Dirk</a>

Hi,

I would personally use domain.com/language for all the sites and use the root to propose the choice of language like this example http://www.volvocars.com/ (which to me seems to be a more future proof solution) if you want to extend your website to other languages or specifically target other regions (example Mexico- which is also Spanish speaking).

1: fully agree - it's much better to translate the url's

2: hreflang - seems ok. You can always check the implementation on http://flang.dejanseo.com.au/ to see if the implementation is ok and/or use this hreflang generator http://www.internationalseomap.com/hreflang-tags-generator/ to create the code.

For the default version - up to you but I would rather go for English as it's more a universal language than Spanish.

3. Geotargeting is not in contradiction to the hreflang tag for the exemple you give - it would have been if you would have set the language to Chinese & geotargeting to France.

4. The language tag you mention doesn't seem to be correct - see also http://stackoverflow.com/questions/4417923/html-meta-tag-for-content-language - rather use  for Spanish,  for French,.. (you could check the specs on this as well: http://www.w3.org/International/questions/qa-html-language-declarations

5. You can use self-referencing canonicals - it's however not necessary to use the canonical to set your preferred version (http://googlewebmastercentral.blogspot.be/2011/12/new-markup-for-multilingual-content.html)

Hope this helps,

Dirk

Hi,

In most cases having duplicate content is not going to punish/hurt you in terms of SEO (unless it's deceptive content) - see https://support.google.com/webmasters/answer/66359?hl=en

It remains however best practice to make sure that content on only one unique url - the example you give seems to be a text book example of 'when to use canonicals' - https://support.google.com/webmasters/answer/139066?hl=en

The fact that Google doesn't seem to index the #! pages is probably related to the fact that these pages have few incoming links and that it's making the correct guess that these duplicate pages are not really important. You should also take into account that the site: command is not necessarily giving you all the pages that are indexed.

Long answer to confirm that you better add the canonical.

Hope this helps,

Dirk

I checked your site with Screaming Frog - the issue with the product compare is solved. There is still a problem with the wishlist.

Example http://www.stopwobble.com/wobble-wedge-white-hard-300-wedges.html  - if you look at the source there are links to https://www.stopwobble.com/wishlist/index/add/product/81170/form_key/XdNIJWsLMTHVFpVh/ which still give 302

You should also correct links of type http://www.stopwobble.com/sales/order/history/ in your HTML

Don't forget that Moz Crawl is only once a week - so the errors will only disappear next crawl.

rgds,

Dirk

Hi

Did you check this article on infinite scrolling from Google Webmaster tools?

Without seeing the actual site it's just guessing - if you have thousands of pages that are listed I guess that it doesn't really make sense to use rel next/previous.

You could consider to only index the first page of the category and put a canonical on the remaining pages.

Are these category pages valuable as landing pages? If not - you could put noindex/follow to make sure that the underlying pages get indexed.

Hope this helps

Dirk

On top of what Alick already mentioned you could also install the Chrome Tag Assistant plugin to double check that your code is really sending data - https://chrome.google.com/webstore/detail/tag-assistant-by-google/kejbdjndbnbjgmefkgdddjlbokphdefk

When your traffic drops to zero is almost certain that there is an issue with the tracking code.

rgds

Dirk

Hi,

Don't think that there is a plugin for this (most people need it the other way round).If you have access to htaccess you could add a rewrite rule which is redirecting all https request to http - see https://sites.google.com/site/onlyvalidation/page/301-redirect-https-to-http-on-apache-server.

Options +FollowSymlinks 
RewriteEngine on 
RewriteBase /

RewriteCond %{SERVER_PORT} ^443$ [OR]

RewriteCond %{HTTPS} =on 
RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]

The other option would be to check if you can optimise the https to render faster - you could check this article (especially the part on SPDY): https://yoast.com/move-website-https-ssl/

Hope this helps,

Dirk

Hi,

While these links may not be visible on the page itself - they do exist in the HTML.

Just take a look at the source code of your homepage & search for the word 'compare' and you'll find links like this:

• class="separator">|<a <span="" class="html-tag">href</a><a <span="" class="html-tag">="</a>http://www.stopwobble.com/catalog/product_compare/add/product/98500/uenc/aHR0cDovL3d3dy5zdG9wd29iYmxlLmNvbS8,/form_key/Vw93RYTNzbI4GGns/" class="link-compare">Add to Compare

which will be followed by bots.

You could put a "nofollow" on these links (probably the easiest solution), block /product_compare using robots.txt - or use javascript to insert the links only when users are logged in.

rgds,

Dirk

Hi,

It's coming from the links in your footer - I attached a screen copy. (the copy is made on http://www.justkeyrings.co.uk/sitemap/ )

Not sure what you're doing wrong - the "bad" link is not always appearing (and it appears with both js enabled/disabled - caching enabled/disabled).

It certainly would not hurt to clean your HTML code a bit - it's should not necessarily pass the W3C validator, but adding basic things like a doc type declaration wouldn't hurt (http://www.htmlhelp.com/tools/validator/doctype.html). It helps the browser to better render your page, I am however not sure that this will help for this specific problem)

Hope this helps a bit with your search.

Dirk

iEMYQLv

Hi,

For e-commerce tracking two options are available - you could use the "normal" e-commerce tracking or the enhanced e-commerce tracking. Enhanced e-commerce is the newest & most advanced way of tracking.

Both would require some additional coding - you can find how to implement them on the links above - or check these articles (Understanding enhanced e-commerce tracking & Implementing enhanced e-commerce tracking).

Hope this helps,

Dirk

Hi,

Both codes are outdated (the first one seems to miss a part) - it's better to use the universal tracking code which looks like this:

This script should be put just before closing the head tag.

You can check the implementation with the Analytics Chrome plugin to see if everything is ok: https://chrome.google.com/webstore/detail/page-analytics-by-google/fnbdnhhicmebfgdgglcdacdapkcihcoh

Rgds,

Dirk

Hi Nathan,

I checked a few pages on the site with the Tag Assistant plugin for Chrome - and there is no tracking code to be found.

Are you sure that the data you see in Analytics is correct (it could as well be referral spam which is being recorded). I have a personal domain with no Analytics code (removed 2 months ago) & still get 20/30 visits/day tracked in the analytics account (mainly referral spam)

rgds,

Dirk

Hi,

It's quite simple - just go to https://moz.com/subscriptions/cancel

(you can also go via the navigation - click on your avatar (upper right corner - select "Billing & Subscription") - on the next page click "Cancel" on your current plan)

rgds

Dirk

Hi,

Check the answer of Cyrus Shepard on this question: http://moz.com/community/q/are-cdn-s-good-or-bad-for-seo-edmonton-web - I fear it will be hard to find other quantified data.

"We've done a lot of studies here at Moz and what we've found is this:

• There does seem to be a slight correlation between site speed and rankings (keep in mind that correlation is not causation)
• Our studies have not found a relationship between CDNs and higher rankings.

So the evidence would seem to suggest that CDNs can help your website speed, and it's possible to help your rankings, simply using a CDN by itself is no guarantee."

Hope this helps,

Dirk

Hi,

If these files are used to render the content on screen - it's not a good idea to block these files from indexing.

Official Google recommendation is to allow these files to be indexed:
"If resources like JavaScript or CSS in separate files are blocked (say, with robots.txt) so that Googlebot can’t retrieve them, our indexing systems won’t be able to see your site like an average user. We recommend allowing Googlebot to retrieve JavaScript and CSS so that  your content can be indexed better.  "

Source: http://googlewebmastercentral.blogspot.be/2014/05/understanding-web-pages-better.html

Rgds,

Dirk

Technically this should be possible - you might want to check this article - http://forums.iis.net/t/1178655.aspx (the best answer is at the bottom of the page) - but maybe the other links provided in the answers can be useful as well

Hope this helps,

Dirk

Andrew,

Your canonical needs to exist - so for the page you mentioned you need to update the url to the one with the trailing slash. In fact - for all pages on your site you should check if the canonical exist (Screaming Frog can do miracles here)

The issue with the https is a bit different - you should not have both versions (http/https in parallel) - so if your https certificate is ok you should put your site in https & redirect the http version to https

This can be done by adding these lines to your htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

If you switch to https - you must make sure that all the resources you call on a page are also on HTTPS - if not, users could get a security warning. There is an article on how to migrate site to HTTPS on Yoast: https://yoast.com/move-website-https-ssl/

If your site is on https - your canonicals need to be in https as well. A tool like Screaming Frog can help you to check that both (https & canonicals are ok) - it's not free - but certainly worth the investment.

Hope this helps - don't hesitate to ask if it's not clear

Dirk

I didn't check all the references of Patrick - but yes, the way you build your url (folders or "flat") will have no impact on how you are positioned in the SERP's (if they contain the same keywords)- so both of the options you mentioned in your original question are equal if you only see it from SEO perspective.

rgds

Dirk

Hi Marie

Couldn't resist to like this - I noticed that you were only missing one like to reach the Moz Walhalla...

Congrats,

Dirk

The resources mentioned  by Patrick are all good ones - I am even going to add one: http://www.bruceclay.com/blog/structured-urls/ . You don't even have to read it :

• structured url's help semantics  - the folder like structure helps search engines understand how the site is structured
• it's easier to check which pages are indexed as you can do a site:mysite.com/folder/
• reporting is way easier with a structured url

Apart from that, and probably most important argument: a site depth is measured on how many clicks you need to get to a page and how pages are cross-linked - Google is not counting the number of "/" in your url's to determine if your site is flat or not.

rgds

Dirk

Hi,

Far from being an htacess expert, but you could also try this rule:

RewriteCond %{REQUEST_URI} /+[^.]+$
RewriteRule ^(.+[^/])$ %{REQUEST_URI}/ [R=301,L]

(off course I didn't invent it myself - it's coming from here: https://github.com/phanan/htaccess#force-trailing-slash )

I tried it here http://htaccess.madewithlove.be/ - and it seems to work if url is in the form
mydomain.com/article => mydomain.com/article/

If you check with mydomain.com/article.htm - it's not redirected

Could be an alternative if the rule proposed by Andy wouldn't work.

Rgds,

Dirk

Hi Pete,

Personally I am not a big believer in trying to funnel link juice across the site - but theoretically yes, if you reduce the number of (unique) links on the home, the more link juice is passed to the categories below.

On the other side, the fewer links you have on the homepage, the more you are pushing content deeper in your site (number of clicks from the homepage to reach pages).

The other point - you can structure your URL anyway you want (best is to keep them quite simple so that they are easy to remember and not too long). For the depth - Google is looking at the number of clicks to reach this page (starting from home) - they are not counting the number of "/" in your url.

Hope this helps,

Dirk

Edit: you might want to check these resources: http://searchenginewatch.com/sew/news/2316757/matt-cutts-on-linking-guidelines-how-many-links-on-a-page - and this one https://moz.com/blog/how-many-links-is-too-many

Hi Andrew,

You use the Yoast e-commerce plugin - and I assume at some point you defined a canonical url for the page you mentioned.
In short - with a canonical url you ask Google not to index this page: https://kidsinministry.org/childrens-ministry-curriculum/?option=com_content&task=view&id=20&Itemid=41 but the url that you have put as canonical url which is this page: https://kidsinministry.org/childrens-ministry-curriculum

In order to respect this request - this url need to exist on your site. However - this url is redirected to https://kidsinministry.org/childrens-ministry-curriculum/ with a 301 redirect (basically stating: hey, this url doesn't exist anymore on this location, but you can find it here).

So, if you update the canonical url from https://kidsinministry.org/childrens-ministry-curriculum to https://kidsinministry.org/childrens-ministry-curriculum/ your problem is solved.

There is no need to redirect https://kidsinministry.org/childrens-ministry-curriculum/?option=com_content&task=view&id=20&Itemid=41  to https://kidsinministry.org/childrens-ministry-curriculum/ as the canonical is already taking care of the duplicate content.

More background info on canonical url's can be found here: https://moz.com/learn/seo/duplicate-content

Hope this clarifies, if not, let me know,

rgds,

Dirk

Hi Pete,

No need to worry about the duplicate links - to quote Matt Cutts (https://www.youtube.com/watch?v=6ybpXU0ckKQ)  - nothing to worry about (as long as it's not 5000 internal links with over optimised anchor)

266 links on the home is a lot - but not an amount of links that is surprisingly high for an average e-commerce site (especially with the duplicates). Regarding the number of links I would rather think about usability than SEO. If having this much links on the page is making it easier for your visitors to go through your site - keep them. If this number of links is making them confused - try to reorganise & regroup the links. A small user test with a few people not too familiar with your site can learn you a lot about the usability factor and how many people are actually using the links to navigate (vs just using the internal search function)

Hope this helps,

Dirk

Thanks for the compliment Egol!

Hi Patrick,

Your method is a good one - I use more or less the same trick to retrieve url's from a sitemap in xls  (it's even faster if you sort the url's in alphabetical order & delete the rows containing priority / lastmod /.. - then you only need to do a find/replace on the <loc>/</loc> )

It's just in this specific case as the sitemap was generated in Screaming Frog that it's easier to eliminate these redirected url's upfront.

Dirk

Hi Justin

The how-to of Patrick is correct - but as you are generating your sitemap using Screaming Frog there is really no need to go through this manual processing.

If you only need to create the sitemap:

Go to Configuration > Spider -
Tab: Basic settings: uncheck everything apart from "Crawl Canonicals" (unchecking Images/CSS/JS/External links is not strictly necessary but speeds up the crawl)

Advanced: Check "Always Follow redirects" / "Respect Noindex" / "Respect Canonical"

After the crawl - generate the sitemap - it will now only contain the "final" url's - after the redirects.

Hope this helps,

Dirk

PS Try to avoid internal links which are redirected - better to replace these links by links to the final destination

Hi Justin

Probably the easiest way to eliminate these cross references is to ask your programmer to put all links as relative links rather than as absolute links. Relative links have the disadvantage that they can generate endless loops if something is wrong with the HTML - but this is something you can easily check with Screaming Frog.

If you check the .com version - example https://www.zenory.com/blog/tag/love/ -it's calling zenory.co.nz for plenty of links (just check the source & search for .co.nz) - both the http & the https version

You can check all these pages by hand - but I guess your programmer must be able to do this in an automated way.

It is also the case the other way round- on the .co.nz version - you'll find references in the source to the .com version

In screaming frog - the links with "NZ" are the only ones which should stay absolute - as they point to the other version

Hope this clarifies

Dirk