Welcome to the Q&A Forum

HI,

I had the understanding that noindexing pages would not stop images on them from being indexed - google runs another bot for images which is different from the 'normal' bot - and the noindex directive is applicable to the PAGE url, not the IMAGE url. There is a discussion here that mentions a noindex tag specific for images which would imply that your images should still be in the index even if you noindex the page. Hope that makes sense!

Hi Amelia,

So in this case you are fine doing it as you are doing and not changing the 'final' url but just shifting the content as you describe after determining a best case. Have fun testing!

Hi Amelia,

Conversion optimization does necessarily need different urls, so I would say that no you do not need to change url unless as you say there is a major change in the topic or SEO optimization of the page that might dictate a change in url also. It depends a bit on how you are doing your A/B testing - are you using software like optimizely or just measuring different pages in analytics? If the latter then maybe your situation dictates separate urls to test and you are bringing in visitors from CPC campaigns (for example) to test - once a decision is made on which version works best you can update the main page that is linked to from your site - keeping the same url of course!

Hi,

There are some differing opinions on the benefits of using base64 images to reduce http requests. From an seo point of view I don't think it will make much of a difference one way or the other if you are only talking about 20 icon images, but from a performance point of view I would use css image sprites which also reduce http connections and are (in my opinion) easier to maintain.

Hi Leonie,

Thats a good question, you wouldn't think it would make a difference, but a couple of weeks does seem like a long time to wait based on others comments (seem to be a matter of a few days in most cases). Not sure what else to suggest other than checking all the technicals again to be extra sure. If you want to mention your domain, I will have a quick look to see if anything obvious stands out...

HI Leonie,

It all looks correct and maybe it just needs time for google to pick it up. Perhaps one thing to check: google states that  you should have a canonical tag on your homepage and that this tag should match the url declared in the code above. In this case your canonical should include the trailing slash, if it doesn't have the trailing slash then you should remove it in the line:   "url": "http://www.mydomain.nl/".

Just a thought.

HI,

It looks like your 'request info' button is spinning out endless urls, try going to any page and then clicking 'request info' a couple of times. You will see these urls being created. It is probably a relatively simple mistake in the code for the button, your developer should be able to fix it.

HI Dino,

Yes the links will still show in external link reports if they still exist. Assuming you have GWT access for the domain in question, you can go to the google disavow tool (https://www.google.com/webmasters/tools/disavow-links-main), select the relevant domain and then click 'disavow links'. it will pop up a window where you can also download the last file that was uploaded to the disavow tool. You can then use this list to cross check against the links you are seeing in the reports to make sure nothing was missed.

HI Leonie,

You should be able to implement it by adding some additional markup to your homepage, you can read more about it here (the page also has some code examples). There is a follow up here pointing out a couple of the common issues that are seen when setting this up.

Hi Akshay,

Third party cart tracking issues like this is one of the common things that the referral exclusion is used for. It is similar to adding the utm_nooverride=1 tag on the return links as described in the article Everett links to below. You can try it and check your data for a couple of days (or just hours) to verify that it is doing what you want, if for some reason it doesn't you can always remove the exclusion. From the analytics attachment you showed - I think it will solve your problem.

Hi,

The easiest way is probably to add paypal.com to your referral exclusion list in analytics. You can read more details on how this works here. Hope it helps!

I only have experience with kentico on non ecommerce sites and would tend to second what others have said about magento being the best of class for ecommerce.

That being said, not sure if the enterprise version changes anything in terms of system setup but kentico is asp/windows based and magento is php based so I would think that the kind of hosting/dev environment you have and the team involved in development would indicate which of these would be a better fit no?

Hi,

If you are seeing the 404 errors in the moz crawl report then these pages are likely still being linked to internally, so it would be good to correct any outdated internal links. You can check where the pages are being linked from by downloading the crawl report and checking the relevant column.

If the links are external then you can 301 redirect the old pages to the most relevant new pages using a 301 plugin. There are a few of them you can check out here.

Hi,

You mean tracking when someone click on a mail link in a page that directly opens up their email client yes?

If so you can track it by adding some js to the link and declaring the click as either an event or a virtual pageview. You can then set up a goal based on the event/pageview to make it easier to track in analytics. This page details the setup (it is for download link tracking but the concept is the same).

My 2 cents: This does look like a wp hack - been having a nightmare with a recent Pharma hack like JV mentions and honestly I still cannot figure out how exactly they got into the site but suspect through an outdated plugin.

A couple of things to keep in mind are to check your htaccess file for weird lines and have a look for non standard wp files in various folders (things like cache.php or ms-writer.php if I recall right). These files were not showing recent change dates however so it was not as simple as just ftping in and seeing which files had been recently changed (still no idea how they pulled that off). It can also be that all these pages are being spun out of a handful of php files (or the database!) so not 100% the case that you would actually see the subfolders (although in some cases you might). Also seen dev versions of wp on the same server that have not been kept so up to date be used to get into the main production version (pretty sure they were indexed through links sent via gmail emails, thanks google!).

You can check the google cache for any of these pages to see what they looked like and when they were last cached for example: http://webcache.googleusercontent.com/search?q=cache:Y0U-2Yyk3y4J:news.mshowells.com/CI/Ugg-Hazelwood-1437.shtml+

Most of them show late August cache dates so that should help narrow the timeframe. Interesting to note that all pages have a bunch of links at the bottom, some to your site some to other (probably infected) sites. All of the links are now 404s so maybe the hack got taken down by the originator (no idea why just a thought since its a bit odd that all of the links on the external sites also seem to be 404ing now). Needless to say, change all wpadmin, ftp etc passwords to be safe!

Hi,

If the high rankings you have on .co.uk are for competitive keywords then I think you are wise to be concerned. Is the site originally from the US or what is influencing the decision to make the en-us version the default with the new site? Keep in mind also what the default example.com will be supporting, would that also be en-us (thereby rendering /en-us/ irrelevant)?

It used to be that using canonical together with hreflang was ok by google but had some odd side effects: If you canonical the uk version to the us version then certain uk searches could see the uk url but with title/meta/content from the us page. That can be ok depending on what your titles/content are like. If your us page title is 'my company USA' then that is probably not what you want uk searches seeing even if the link lands them on the uk page in the end. It also usually meant that the uk pages CONTENT itself was not searchable in google, so if the page for example had the only mention of a uk phone number then this number would not show up in google serps.

That being said, it seems that google has changed the guidance on using canonicals and hreflang together and is now suggesting only using canonicals within the same language/region set. Check here and the comments here for some more details. Soooo.... not sure if that helps answer your question much more!

Hi,

It sounds like the setup should do what you want and not hurt visibility as such. It would be worth checking google webmaster tools for indexed pages to verify that the canonical urls are the ones that are indexed and there is not a large difference between total products/pages on the site and what google has in the index - which might indicate an issue.

If the product range does not change much then it would be worth editing the sitemap to show the canonical urls. Having non canonical urls in the sitemap isn't ideal since it ads an extra step between the urls you are declaring and the urls you want in the index. That being said I have seen magento installs with similar issues with the sitemap urls and have not noted any major problems.

HI Benoit,

If the site is very new and has no incoming links yet I would think that google is still trying to decide what it is all about and how best to present the data in the serps and that is why you are seeing the contact data in there (also the type of search you are doing - an exact match for the domain - could be influencing the type of data returned). Give it a bit of time and the description should change around and settle.

The date is mentioned in your source code (view source and search for 'vcard' and you will see a hidden div with author and date info in it). So google is likely thinking your site is a blog and adding date info to the serps. Getting this hidden code completely out of the template should help getting the date out of the description.

It should be redirecting to index.php as long as a number of conditions are met:

rewritecond $1 !^(index.php|public|tmp|robots.txt|template.html|favicon.ico|images|css|uploads)
As long as the requested url does not start with one of: index.php, public, tmp, robots.txt, template.html, favicon.ico, imagesloss, uploads and,

rewritecond %{REQUEST_FILENAME} !-f
rewritecond %{REQUEST_FILENAME} !-d
As long as the requested url is not an existing file or directory

Then:
rewriterule ^(.*)$ index.php?link=$1 [NC,L,QSA]
Rewrite the url to index.php?link=REQUESTED-URL (along with any other url variables) and stop processing

So you should be seeing urls something like index.php?link=page.php or similar if the conditions above are met.
robots.txt is not being redirected since it is being specifically excluded in the first line.

Think I got that right, hope it makes sense!

That code should automatically 301 redirect all urls with www in them to non www versions - you can check if this is working properly with this tool (for the moment I do not see the redirect working though).

So for any duplicates you are seeing because of that specific issue this will fix them.

You should then wait for the next moz crawl to happen and should see less duplicates (since these ones will be removed) - this will show you what duplicate issues are still apparent (as mentioned there are a number of reasons that duplicate content can occur) and then you can focus on what kind of duplicates they are and what fix(es) may be needed to address them.

It is best to fix one thing at a time and not pile a whole bunch of changes you are not sure about on top of each other - it keeps it easier to bug track if something goes wrong!