If the UA code is the same for both trackers you can delete the async version and only keep the universal version. You should know however that the reported traffic probably will drop (as same traffic was measured twice), your bounce rate will go up and time on site go down.

Dirk

Maybe Google is desperately trying to find a page which is replying within in reasonable delays... Time to first byte is horrible: http://www.webpagetest.org/result/151104_SQ_WXJ/1/details/

Apart from the speed issue - the 301 as proposed by Justin is the best solution;

Dirk

Hi,

Normally these rules should do the trick:

RewriteEngine On

removes the index (source:http://dense13.com/blog/2012/10/29/removing-index-html-with-mod_rewrite-in-htaccess/)

RewriteRule ^index.html$ / [R=301,L]                              
RewriteRule ^(.*)/index.html$ /$1/ [R=301,L]

adds a trailing slash (source: http://stackoverflow.com/questions/21417263/htaccess-add-remove-trailing-slash-from-url)

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*[^/])$ /$1/ [L,R=301]

Dirk

Hi Dan

universal is the last version - async was the previous one. If in doubt you can always check here which version you use: http://www.statstory.com/how-to-identify-which-version-of-google-analytics-you-are-using/

Dirk

Hi,

The 302's are coming from redirects from https to http - example: https://www.cheaptubes.com/product-tag/monlayer-graphene-on-cu/ is redirecting to http://www.cheaptubes.com/product-tag/monlayer-graphene-on-cu/ with a 302 (you seem to have a lot of these redirects)

There also seems to be an issue with your url's. You have quite a large number of 4xx errors - mainly caused by trying to call .js files that normally would reside on the root & you try to call on a product page - example: http://www.cheaptubes.com/product/f-functionalized-graphene-nanoplatelets/js/foundation.min.js - while this file is actually on http://www.cheaptubes.com/wp-content/themes/cheaptubes/js/foundation.min.js - so I guess something is wrong with the way you construct your internal links.

Hope this helps,

Dirk

Nope - Moz is completely unaware of settings you define in Google Search Console.

Why don't you pick a preferred version & 301 redirect the other one to the preferred one?

Dirk

If the header checker indicates that the redirect isn't properly setup you will have to check the redirect rules. You could try to double check with web-sniffer.net. If the redirects are not ok waiting doesn't make sense - Moz will continue to find these errors (and Google as well).

Also indicate the preferred domain in Search Console (you will need to register both of them - the www & non-www version)

Dirk

Hi

as this is already a post which is markdr as answered it's better to make a new question and to reference this one (else nobody will notice). I would however strongly advice to ask this question as well on a more technical forum like stackoverflow.com

Dirk

Hi,

You might want to try this solution:

Redirects domain.com/file.php to domain.com/file

RewriteCond %{REQUEST_FILENAME} !-d                      # is not directory
RewriteCond %{REQUEST_FILENAME}.php -f               # is an existing php file
RewriteCond %{REQUEST_URI} ^(.+).php$                    # request URI ends with .php
RewriteRule (.*).php$ /$1 [R=301,L]                                 # redirect from file.php to file

Source: http://stackoverflow.com/questions/1992183/how-to-hide-the-html-extension-with-apache-mod-rewrite (2nd answer)

Dirk

To be honest - best strategy in this case seems to try to contact the site owner.

It looks like a genuine site but if you do the site: command in Google you'll find plenty of strange pages (about minecraft, Ducati club, ...etc) all in the same strange layout as the page you mention. Probably the site got hacked and needs cleaning.

If contacting the owner doesn't help - you can always try file the Spam and/or DMCA report.

Dirk

Hi,

I think that you are using the Google Analytics plugin for Drupal - which seems to track events by default (search "event" in the source code).

You might want to correct the pdf download - it's currently generating a 404

Dirk

Moz had a similar caching issue one week ago (/ugc/ content cached instead of /blog/ pages). They posted this question on Webmaster forum - may be the answers can help you find a solution (there was an answer from John Mu as well).

Dirk

Hreflang is reciprocal - so if page A indicates page B as equivalent - page B has to declare page A as equivalent.

If I understand your question well - you want to have 2 English pages with a hreflang pointing to the same Spanish page. This is not possible.

Dirk

Hi

What you see is the data Screaming Frog is pulling in using the API from Analytics - it's not to check if Analytics code is present on all the pages.

Dirk

Normally at the bottom of the graph you see a message stating "Table omitted as it contains no additional information. Select Queries to see the top queries for the current results"

Once you have set the filter on the page you'll have to click on "Queries" again to see the queries that correspond with the page you have put in the filter.

Google does everything to make our live easier...

Don't think it's still good practice. Google bot has evolved from a simple txt browser to a kind of mini version of Chrome.
It is perfectly capable to assess where the content is located on your page. Trying to trick Google to think that content at the bottom is in fact on the top because it's appearing first in the HTML is not going to help.

No real hard evidence - just my opinion.

Dirk

Yes, issue for everybody. Check https://www.seroundtable.com/google-search-console-search-analytics-stuck-21705.html

Dirk

If Moz is crawling them it implies that somewhere in the source of your page you are linking to these url's. Try crawling your site with a tool like Screamingfrog & check which pages are generating these links. Then look in the source of the page - it should be somewhere in the code.

It would already help if you would put a canonical url like http://www.example.ch/de/example/marken/brand/make-up/c/Cat_Perso_Brand_3 on the page.

Dirk

You don't have to put index & follow - that the default behaviour. It's only when you don't want to be indexed or links to be followed that you have to indicate it.

Rel next/previous have to be in the header - check https://support.google.com/webmasters/answer/1663744?hl=en  - not on the links themselves.

Dirk

Normally it shouldn't count as a bounce as you stay on the same domain.

As you are using two different Analytics accounts however it will count as a bounce. The first account is not aware that the visitor is continuing his visit on the blog section and vice versa. The fact that different CMS is used has no impact.

I would suggest to use one analytics account to track both main domain / blog.

Dirk

Hi

Google is being nice & is doing exactly what you ask it to do.

Example: http://www.customlogocases.com/custom-motorola-phone-cases-printed-logo/ - in the source you put:

rel="canonical" href="http://www.customlogocases.com/custom-motorola-phone-cases-printed-logo/?limit=all"/>

So - you ask google to show http://www.customlogocases.com/custom-motorola-phone-cases-printed-logo/?limit=all in the search results rather than http://www.customlogocases.com/custom-motorola-phone-cases-printed-logo/

Update the canonical & remove the limit=all & the problem will be solved.

Dirk

Even if the new static page is 100% optimised - if all the internal links on your site are pointing to the less optimised dynamic version of the page, it will still be the dynamic page that will be listed.

If the content is quite similar - you could put a canonical url on the dynamic page, pointing to the new static version. This way you indicate to Google that you prefer the static version to be indexed.

Another possibility would be to redirect the dynamic page with 301 to the static version, my guess would be that this would be more difficult to do.

Dirk

The code looks ok on first sight. I assume you are checking the code on one of the domains - and not on domain-test.be or something similar. Did you try the Chrome analytics plugin to check the errors that are generated?
If you don't want to disclose the site - send the url in pm & I'll have a look.

Dirk

You could launch it on the .com.au extension - but I fear that the geotargeting resulting from the ccTLD is a much stronger signal for Google than the ahfref tag.

Not sure if this link is still valid but it states:

Q: Does “rel alternate hreflang” replace geotargeting?
A: No. This link-element provides a connection between individual URLs, and only allows Google to “swap out” the URLs from your site currently shown in the search results with ones that are more relevant to the user. It does not affect ranking, as geotargeting would.

Check this video from Matt Cutts (2013) on how Google deals with ccTLD's: https://www.youtube.com/watch?v=yJqZIH_0Ars

If your dot.com domain is not available - try if some of these generic tld's is available for your domain - and redirect to the .com as soon as you can. It's not optimal - but I honestly think that the .com.au/us/ solution is not going to work.

Dirk

In your sitemap you only have to link to the pages on your site - there is no need to add a link to the robots.txt file.

Your robots.txt is always on the root of the domain (yourdomain.com/robots.txt). In your robots.txt you can put the location of your sitemap(s) - just put the following line(s) at the end of the file. It is possible to add multiple lines if you have multiple sitemaps. Alternative would be to put a link to the index type of sitemap which contains the links to the different sitemaps you have.

Sitemap: http://www.yourdomain.com/name_of_your_sitemap.xml

It is not strictly necessary to add the link to the sitemap in your robots.txt - you can also just indicate the location in the Search Console (Google) / Web master tools (Bing)

Dirk

It has no SEO impact (*) but you shouldn't use analytics campaign tracking for measuring internal links as it will mess up your data.

Several other options exists - like event tracking or custom dimensions. There is an interesting article from Cutroni on the subject you might want to check out.

Dirk

(*) provided that your destination url is using a canonical url - if not you could have duplicated content issues as both the domain.com/article.htm?utm_source=Blog&utm_medium=Widget&utm_campaign=FromBlog & domain.com/article.htm will exist

Hi,

The Moz suggestion on the canonical is to put a self referencing canonical - not to put a canonical on the subpage to the homepage (or the other way round). Canonicals should only be used to avoid duplicate content - which is I guess not the case with your homepage/subpage.

The fact that Google prefers to show your homepage rather than your subpage is something which isn't really 100% under your control - without the actual site it's nearly impossible why this happens. My guess would be that your homepage probably has a higher authority (more incoming links) which Google could prefer over optimised content. If you browse the q&a you'll notice that you are certainly not the only one in this case;

Dirk

To be honest - I would change web designer. Making your site responsive is all about reformatting your existing content to make sure the layout adapts to the used device. The main work is done in the css - not in the HTML.As far as I understand your question your webdesigner is duplicating the same content in the HTML, which normally shouldn't be done in order to make your site responsive.

To answer your question - the content will be appearing twice - once visible - once hidden depending on the device /type of Google bot. Google could consider this as spamming, or just ignore the part which is hidden, difficult to tell. You will in any case have a bloated HTML code which could have an impact on the load times of the page.

Dirk

Not sure if it's going to work but Karolina Netolicka seems to be product manager for Google Finance - you could try to contact her via her Google Plus Account - alternatively send her an invite / Inmail to her Linkedin Profile - she's also the one who posts on the Google Finance Blog

If you know the syntax of general Google adresses - you could try that as well (very often it's something like firstname@google.com or (firstletterfirstname)familyname@google.com)

Good luck,

Dirk

If it's only about the H1 - if you look at the source the H1 tag is commented

Example; http://runforcharity.com/start-to-run/get-off-that-couch/getting-fit-for-a-marathon - H1 tag in source:

Seems more an issue with your developers than content.
The main title on that page is GETTING FIT FOR A MARATHON - which is the H2 title. I would change this to the H1?

Dirk

It think Screaming Frog is going nuts on the formkey value in the url which is constantly changing when changing pages.

Could you modify the settings of the spider to respect noindex & respect canonical - looks like this is solving the issue.

Alternatively you could rewrite the url to ignore the formkey (remove parameter)

Dirk

Hi,

If you would have asked this question before April 21st I would have said to publish the responsive pages the moment they were ready, even if the remaining pages are having a different design.

At this point, it seems that the impact of Mobilegeddon is quite limited, so if you can finish the complete site in a couple of weeks, I would rather go for the better user experience and present the full site with the new design.

If in the next days the mobile update would have serious impact on search results, you can always decide to publish the pages which are already responsive.

Keep an eye on this post - https://moz.com/blog/day-after-mobilegeddon - if the update really starts having an big impact, you'll read it there. (or follow Moz / Searchengineland / Searchenginewatch / ... on twitter & you'll be to first to know)

rgds,

Dirk

The issue you have is quite similar to the issue you had previously https://moz.com/community/q/sitelinks-issue-different-languages - the same answers apply.

When I check the cached version of the .com version I get the French site

Personally I think you're IP detection system is messing things up. Checking your headers (from Belgium) I get this:

|

HTTP/1.1 302 Found

HTTP/1.1 302 Found

HTTP/1.1 301 Moved Permanently

HTTP/1.1 200 OK

| http://www.revolveclothing.fr/?nrv=true |

Your robots.txt file is used to give instructions to bots visiting to your site - which parts can/cannot be visited.

If your page is in the cache - you are probably allowing the bots to visit the page (else it wouldn't be there). The reason why you are redirected to the homepage should have another cause. Are you using a meta-refresh? Javascript or htaccess redirects?

You could try to check what's happening by copying the cache url in httpstatus.io - url to use is

http://webcache.googleusercontent.com/search?q=cache%3A< <insert your="" encoded="" url="" here="">- to encode your url you can use http://meyerweb.com/eric/tools/dencoder/</insert>

Dirk

Hi Ronell,

Nice ideas but when you do a post to promote Youmoz you might also consider speeding up the review process a bit. Not really motivating if you submit a post to get the message "We'll review your article as swiftly as we can, but because of the high volume of posts we receive, it could take several weeks for us to get to yours. ".  This is not really in line with your answer to the question of Donna ("Turnaround has more to do with the quality of the post than anything else") - you can't judge the quality of a post before reading it.

Dirk

Even if you implemented all the tags correctly there is no guarantee that Google will show the them in the SERP's - the choice whether or not to show them is entirely up to them.

I guess you already checked if all the tags are properly implemented (if not - check here or here)
You could also check this page for the usage guidelines (bottom of the page).

Again - even if you are doing everything correct & you meet the guidelines - it's entirely up to Google if the snippets will be shown or not. You can't control it.

Dirk

In the menu 'url rewriting' you can simply put the parameters the site should ignore (like date, formkey,..). I removed the formkey parameter and I checked the pages of the archive in Screaming Frog.

It is clearly able to detect all the internal links on the page - so will crawl them.

How are you certain that the pages below are not crawled - could you give a specific example of page that should be crawled but isn't?

Dirk

Hi Ronell

Just to clarify - I don't argue that there is a the link between review time & quality of the post. I am quite happy with the quality of most of the  posts on Youmoz so you are certainly doing a good job.

I am not a native English speaker. If I get a message that it can take weeks before an article is reviewed for me this is equal to "it can take weeks before we read your post". Hence my remark - you can't judge the quality of a post before reading it and so your reply to Donna sounded a bit odd to me.

I understand from your answer that you do a quick review of the new posts every day. Probably it would be better to state this in the initial message (we did a quick review and it's a gem/interesting but will need some rework/needs to be completely rewritten/completely rubbish) rather than stating a generic message that it will take weeks to review.

Reading between the lines - by getting the generic message I understand that my post is simply not good enough at this point and is hidden somewhere at the bottom of the pile

Dirk

Don't know if you did changes in the mean time - but if I check the url you seem to do it ok:

• you use canonical url's to strip the parameters from the faceted navigation
• you use rel next/previous to navigate between pages

The second url you mentioned will probably not appear in the index due to the canonical.

Dirk

You have an issue with your hreflang tags, which seems to confuse Google.  You can use these tools to check your implementation: https://flang.dejanseo.com.au/ or https://technicalseo.com/seo-tools/hreflang/ - both indicate issues with your implementation. Main issue is the fact that the self referencing hreflang tag is missing (check https://support.google.com/webmasters/answer/189077?hl=en). You could also add a x-default url - for the languages/countries that are not specified - pointing to one of the versions.

Personally I would remove the strict limitations on the de / fr version - why would you send austrian visitors to the .com version and not to the /de-de version -> I would rather use hreflang="de" in this case - idem for fr (unless you don't ship to these countries)

On each of your pages you should have all the tags. Example for your home:

Hope this helps,

Dirk

To quote Google: Duplicate content generally refers to substantive blocks of content within or across domains that either completely match other content or are appreciably similar.

Having one image on two different posts - even when alt & title are identical will hardly qualify as duplicate content. A lot of sites (even well known publishers) are reusing the same images on their pages - if you're talking about stock photos - these are used on millions of sites. You won't be able to rank them for Image Search - but they won't hurt you either.

Dirk

Was a bit to quick in my first answer - on first sight it looks ok - but you messed up the canonicals.

All variations of http://www.key.co.uk/en/key/plastic-storage-boxes#orderBy:5&pageView:list& have a canonical url http://www.key.co.uk/en/key/plastic-storage-boxes - which is great as it's strips away the parameters. It also has a rel next pointing to http://www.key.co.uk/en/key/plastic-storage-boxes?page=2 - which is fine as well.

However - the second page (if you start from the ugly url http://www.key.co.uk/en/key/plastic-storage-boxes#orderBy:5&pageView:list&) has url http://www.key.co.uk/en/key/plastic-storage-boxes#productBeginIndex:30&orderBy:5&pageView:list& - this page has a canonical url http://www.key.co.uk/en/key/plastic-storage-boxes - in fact that page should have the canonical url http://www.key.co.uk/en/key/plastic-storage-boxes?page=2

The coding on the "clean" (=canonical) versions of your url are fine. Check https://support.google.com/webmasters/answer/1663744?hl=en - there is an example listed which is quite similar to your configuration.

Dirk

Sorry for late reply - you also have to add the self referencing version; check the example on https://support.google.com/webmasters/answer/189077?hl=en (so each of the versions of the page will have the same block of hreflang urls)

Apart from that  - reciprocal means if page A as hreflang to page B - B should have a hreflang to A. I don't really see why the tool indicates this error as the pages are cross referencing each other - could be caused by the missing self referencing version.

There is a nice tool to generate the hreflang's - http://www.aleydasolis.com/en/international-seo-tools/hreflang-tags-generator/ - you could try it & compare the generated version with what you actually have on your page.

Dirk

Hi,

You could check http://referencement.abondance.com/ (France) - not really rocket science but it covers the basics and quality should be ok. Other sources could be http://www.livre-referencement.com/ (ebook or book). Not associated with them, and didn't use them either, so I can't judge the quality. Abondance is referenced on http://ceseo.org/certification/preparer-lexamen/ - CESEO is an organisation which aims to improve the quality of the SEO consultants in France.

Hope this helps,

Dirk

If you check the Q&A you're not the only on to encounter this problem. In some of these cases it was caused by IP detection systems which automatically selected the country website based on IP (which caused problems because main Googlebot is using a US ip address) - I assume this is not the case with your site?

It's quite possible that it will solve the issue. Easiest way to check is making the modifications and check after a few days if the problem is solved. If not there is probably another issue.

Dirk

Bonus: You indicate that you don't have problems with 404's - but your site isn't exactly clean concerning the internal links. Can't crawl using Screaming Frog given the 503 I get - but manually checking few pages it seems you have mal formatted links:

Classic Car Insurance (the .com is missing) - it's not a 404 but DNS lookup error

I would do a full scan with Screaming Frog to check what other technical issues you have on the site.