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
Welcome to the Q&A Forum
Browse the forum for helpful insights and fresh discussions about all things SEO.
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
Hi,
You might want to try this solution:
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
We did something similar in the past. Changing the servers won't make any difference as long as the front-end part isn't changing. Google doesn't care if your site is running on one or multiple servers, or if two parts of the sites are running on different technology, as long as the user experience is not affected.
If you are changing your URL structure at the same time - there are some things you will have to check. There was a post on Moz a few years ago on site migrations that could help. Basically you will have to check that all your current url's are properly redirected to the new ones and that performance of the new site is ok.
Dirk
Don't have hard evidence - but from my personal perspective: My browser is set to be-nl (Belgium)- when I'm in the Netherlands (nl-nl) I am automatically redirected to google.nl & all the results I get are from the Netherlands (even for international sites were Dutch Belgian versions exist). Browser language will have an impact - but in my opinion proximity will be more important.
Dirk
There is a very useful & detailed post on site migration on Moz - I used on two previous migrations and it worked great (no traffic drop at all) - check https://moz.com/blog/web-site-migration-guide-tips-for-seos
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
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
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
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...
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
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
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
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
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://www.revolveclothing.com/ |
|---|
HTTP/1.1 302 Found
| http://www.revolveclothing.com/?nrv=true |
|---|
HTTP/1.1 301 Moved Permanently
| http://www.revolveclothing.fr/r/Homepage.jsp?nrv=true |
|---|
HTTP/1.1 200 OK
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
Don't know if you did changes in the mean time - but if I check the url you seem to do it ok:
The second url you mentioned will probably not appear in the index due to the canonical.
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
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.
It's a very thin affiliate site with 0% original content (all content = Amazon). On top of that - its quite heavy to load, has no optimisation whatsoever (H1/Meta/..etc); several elements on page that return 404 status, low pagespeed scores and as it is new, no incoming links.
You could check the logs - it's quite possible that Googlebot hasn't discovered the site yet. If it has visited, it probably considered the site too low quality to index. If not visited, you could register in Search Console and do a "fetch like Google".
It will probably put some pages in the index - but there is no chance that with the current content this site is going to rank.
Dirk
Sorry Peter - I was first - the reward is mine 