Welcome to the Q&A Forum

I did - but if I wanted to cancel the subscription I did minimal effort to find out how I could cancel it.

Just do this search query in Google:

refund site:moz.com/community

• you'll get >200 results. If you're active in a community (on a voluntary basis) it is annoying to see the same question popping up because people are too lazy to search for themselves.

@nateknox & @rachel.cachel: This question is more than 1 yr old - apart from the original poster & the people who replied nobody is seeing the questions you ask. If you need help - post a new question in the Q&A

It seems you have a system which redirects users to the default page.

When I try the site http://www.mercimamanboutique.com/ - It has a canonical http://www.mercimamanboutique.com/fr-fr/ - when I switch to German and go back to the same url it has a canonical http://www.mercimamanboutique.com/de-de/

The site seems to exist in https & http - may be better to redirect everything to https (although this is probably not related to the issue you encounter)

Dirk

Update:  I also noticed that the main rel alternate doesn't exist - http://www.mercimamanboutique.com/ is redirected to http://www.mercimamanboutique.com - I guess it's better not to use url's that are redirected but to use the final destination url

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

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

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

It's probably a good thing - I would keep them blocked.

Check https://www.mattcutts.com/blog/search-results-in-search-results/ - quote "Use robots.txt to prevent crawling of search results pages or other auto-generated pages that don’t add much value for users coming from search engines."

Dirk

You should avoid redirection chains; ask your programmer to redirect http://www.colocationamerica.com/dedicated_servers/linux-dedicated.htm directly to https://www.colocationamerica.com/linux-dedicated-server. There is no need to have the step in between (it's just wasting crawl time of the bots)

This is the Q&A - if you want a refund you have to contact support. There is an online form here: https://moz.com/help/contact/pro - alternative you can use help@moz.com.

Some advice - next time you start a free trial of a tool please read the conditions. The Moz trial page clearly states

"I agree to the Moz Terms of Use and understand that this is a recurring subscription. I will be billed automatically on a recurring basis unless I cancel." (bold added)

It's not really hidden & you have to check the box before you can start the trial.

You could use the data from the search console to do that. Some resources that could be useful:

- https://moz.com/blog/how-to-use-search-analytics-in-google-sheets-for-better-seo-insights
- https://moz.com/ugc/how-to-get-the-data-you-need-from-googles-search-analytics-api
- http://searchwilderness.com/gwmt-data-python

Dirk

Hi Anirban,

The impact of adding the few lines of extra code of schema.org will be zero on the load time of your pages.

Apart from that, serving different content to bots & human users could be considered cloaking by search engines.

Implementing schema.org on the normal pages should do just fine!

rgds,

Dirk

Hi,

You should redirect the old url's to the new ones using a 301 redirect. Normally it's not really necessary to submit for re-indexing, Google is quite good in finding new url's itself.

The fact that Screamingfrog still finds the old url's is a sign that on your site you are still using links to the old url - you should update the internal links to the new url (you can easily get this info from Screaming frog - take the url's that have a 404 - check at the bottom of the page "In Links" - this will give you all the pages where the links need to be updated.

rgds,

Dirk

Great video Matt! Should be 'obligatory' to watch this video before posting the first question.

Hi,

Why would you do that for? A coming soon page has no value for visitors, and as a result no value for search engines.

If you're going to create a new site, I would first launch the new site and then redirect the old pages to the new ones.

rgds

Dirk

According to Google webmaster guidelines - a sitemap for users still has some value:
Offer a site map to your users with links that point to the important parts of your site. If the site map has an extremely large number of links, you may want to break the site map into multiple pages. (source: https://support.google.com/webmasters/answer/35769?hl=en)

I agree with Patrick that now most people don't bother to consult sitemaps  - if they need to consult it to find their way on your site you probably have a UX problem.
For SEO purposes - it still can have some advantages:

• it can ensure that your site becomes flatter (content is less clicks away from the homepage)
• Google wants that "Every page should be reachable from at least one static text link." .A HTML sitemap can help with that as well - especially if you have a highly dynamic site where a lot of content is only accessible by (product) search

Sites like Linkedin.com still use these HTML indexes (although they are not called sitemaps but member lists) - as you can check when you visit the site in "Incognito" mode in your browser.

rgds,

Dirk

Google Academy http://www.google.com/analytics/learn/index.html would probably be a good starting point. Or just trial/error with some support from online help. It's pretty self-explanatory.

rgds,

Dirk

You can use Screaming Frog to identify the pages with highest load times as well as the heaviest images. Also check speed reports in Analytics (Behavior > Site Speed).

Once you identified the slowest / heaviest pages you can do more detailed testing using Google Pagespeed Insights (can be called directly from the Site Speed report in Analytics) and webpagetest.org.

You don't need to check all the pages on your site - checking a few different templates should be sufficient to identify the most urgent issues.

Dirk

I think these names would be fine and following google guidelines for image search (https://support.google.com/webmasters/answer/114016?hl=en) - quote: "The filename can give Google clues about the subject matter of the image. Try to make your filename a good description of the subject matter of the image. For example, my-new-black-kitten.jpg is a lot more informative than IMG00023.JPG. Descriptive filenames can also be useful to users: If we're unable to find suitable text in the page on which we found the image, we'll use the filename as the image's snippet in our search results."

rgds

Dirk

The main reason to use internal "nofollow" links on your site if the links would go to technical pages like login pages, or links to pages that you don't want to have indexed. As Ryan says - if you link to other relevant articles there is no reason to use nofollow.

Dirk

Hi,

The difference between them

• canonical : url has a canonical url - which can be self-referencing (canonical url = url) or not

• canonicalised: url has a canonical url which is not self-referencing (canonical url <> url)

• no canonical : quite obvious - the url has no canonical.

Potential issues could be - url's that you would like to have a canonical don't have a canonical or url's that are canonicalised don't have the right canonical url. You can use the lists (both canonicalised & no canonical) from Screaming Frog to check them - but it's up to you to judge whether the canonical is ok or not (no automated tool can guess what your intentions are).
Typical mistakes with canonicals: all url's have the same canonical url (like the homepage), or have canonical url's that do not exist. You could also check this with Screaming Frog using the setting "respect canonicals" - this way only the canonical url's will be shown in the listing.

Also keep in mind that canonical url's are merely a friendly request to Google to index the canonical rather than the normal url - but it's not an obligation for Google to do this (check https://support.google.com/webmasters/answer/139066?hl=en quote: "the search results will be more likely to show users that URL structure. (Note: We attempt to respect this, but cannot guarantee this in all cases.)"

Dirk