Rosemary, Gaston is right--we generally list our sitemap URLs in the robots.txt file, which typically is enough for the search engine crawlers to find them. Keep in mind, though, that a sitemap file or files isn't really required at all if you have a really good site structure.

Felix, there is a good chance that this is referral spam. The goal of a referral spammer is to get you to notice those URLs, and investigate them as if they are sending traffic to your website. Typically, those visitors won't stay long on your website, and they won't have your domain name as the "hostname" in Google Analytics.

Take a look at the traffic and see if it does have a hostname associated with it, and if it's actual human visitors. I bet it's not.

Dieter, one other way you can do this is to use a proxy service. There are several proxy services out there, such as SurfEasy, Strong VPN, or Hola that allow you to surf the web as if you're actually surfing from another country. You can choose the country and then you'll use a VPN to access the sites you need to from another country.

Excal, I've always looked considered the links that are shown in Google Search Console to be a "snippet" of all of the links to your website. For example, there are links that I know are pointing to our website that are good links--but they come and go in Google Search Console. They don't show us all the links. So, just as  you have seen them go away, there's a good chance that they will come back and be listed again.

I do know that the more often you download the links the more often they will refresh the list of links.

smmour, we've actually noticed this as well, this past week. One site in particular that I'm familiar with shows a date from February 2012 on the site's home page even though the Google cache date shows that the page was cached just the other day.

Google typically does take the pub-date from a site and uses that typically, especially if it's in the code of a site using WordPress. However, what you're describing sounds more of a Google problem than a problem with your site in particular. Based on the fact that we've noticed this as well, this past week, it appears to be something that you haven't necessarily done.

What intrigues me is the fact that the domain name wasn't registered and the site wasn't live in 2010, the date that it is showing.

Stephanie, Logan is correct--we used to submit blog posts on YouMoz, and they could have the potential to be boosted up so they would show up differently if the post was good enough. That has been paused for now, and I'm looking forward to being able to contribute again.

Jeremy,

The correct answer to your question is that it needs to look natural. I wouldn't necessarily optimize the anchor text and the link so that it's pointing to one particular page or even your home page with certain anchor text.

If it's your author bio, then naturally it should point to your site's home page. An alternative would be to create/write a page specifically for your author bio (where you list your articles that you've written).

Based on our experience, we generally think that as long at you're on the same website, links should open up in the same window. They should not open in a new window. If you are going to open a link in a new window, then you'd want to notify the user that you're going to do that by telling them before they click the link.

For example: this is a link (opens in a new window)

This is a general user experience issue. While I don't necessarily have any specific stats to show, it just makes sense.

Generally speaking, in our experience, it's not worth it to take the time to change filenames (and thus change URLs) unless you absolutely have to. If you're still using the same CMS, then just changing the URL might not be worth it, as you have to take time to set up a 301 redirect from the old URL to the new URL.

What it would be worth it to do is to go with a flat file structure, such as domain.com/category/page or domain.com/page/. In the long run, you won't generally have to change URLs in the future if you move to another CMS.

If those pages are ranking well with the current URL, you may not want to change the filename. But, if they aren't ranking on the first page, it should be fine to change the filename. Don't forget to set up 301 redirects from the old URL to the new URL.

Marcus, I know this is frustrating. I've checked several things, and looked at many of the possibilities that you've already brought up. I don't have access to the Google Search Console, so I cannot comment about any of that data. I'm assuming that you don't have a manual action on the site or any other messages from Google.

What I've seen in the past is issues with schema markup, especially when it comes to reviews and how they're handled on sites. I'm not saying that this is the issue--but I've seen issues that Google has had with these (especially because there is the word "hidden" there in the code). So, you might look into that some more.

The issue could also be related to links--look at the links to the site's home page to see if there is an issue with low quality links pointing to that page or other unnatural links.

If someone has copied the page, added a canonical tag, and then added a "meta noindex tag" to their page, it's possible that they could have taken your page out of the index. This has happened before.

Gabriel, the "readmore" URL is going to be the first URL that Google indexes, as that URL is typically on the "main blog page" of your blog. Since you update that page on a regular basis (by adding more posts) and the page has been around for a while, Google monitors that page and then updates it fairly quickly.

It takes more time for the blog post itself to get indexed, and socializing the post (such as Tweeting the URL) will get it indexed faster than just waiting for Google to crawl. There are a lot of factors that Google uses in order to determine indexing speed and pages that they add to the index, though.

Since you're using "read more", though, that is a good thing--generally you won't run into duplicate content issues because only a snippet of the post is on the site's main blog page (and category pages, etc.) and not the full blog post. So, that's a good thing.

Neil, the others are right--you should first show the full content and not hide any of the content on the page like you're doing. Depending on the size of the content, though, you might consider why you're hiding the content in the first place, as you might need to create more pages on your site for that content. Adding the content to new pages on the site might be good for your users, and certainly will fix your problem.

When considering the content and indexing, though, if the content is in the page source code then it will be indexed. Google does know if it's hidden, though, as Googlebot, Google's crawler, is essentially a version of Google Chrome.

Roy, this is definitely a complex task--which should take careful planning and organization. The steps that are outlined in the link that you provided is a good start, but that's only a small part of what needs to be done .There are a lot of sub-tasks that need to be taken care of in between those larger tasks.

When it comes to moving site A to B, there is no site C involved--so just think about it as if you're moving site A to C and then B to C. Or, you could also first think about combining both sites and rather than moving site A to B you can choose the best content on each and then just move them to site C.

What's important, though, is to figure out which content and pages are duplicated on both sites and then choose the best page(s) and move those to site C. There will be content that's essentially not on both sites, so those can just be moved. The key is to spend plenty of time organizing the content and deciding which content can go away, which needs to be moved, which needs to be combined, and soforth.

There is one major step that's missing in that other list, which is to use verify all sites (http and https, as well as http://www and https://www) in Google Search Console, set up those 301 redirects, and use the Google Change of Address tool to tell Google that the site's moved.

There is also a mention of rel canonical, and since the sites are moving entirely, canonical tags won't be appropriate to use. You'll need to use 301 Permanend Redirects to move the content from one site to another, especially since site A and B won't exist anymore (they'll be redirected).

Overall, if you are going to translate your website, it really should be translated by a human rather than an API. There are certain ways things should be translated and written that an API just cannot do properly. It's more of a user experience and readability issue than anything else.

It sounds as if the screaming frog crawling issue isn't related to the translation issue--it is a crawling issue. You may want to see if you can crawl much slower, which is a setting in screaming frog.

Generally speaking, these types of schemes don't work, as Google is quite aware of people trying to do this. With the latest Google algorithm updates in the past few years, we've seen it become tougher and tougher for black hat SEO or gray hat SEO to be successful by trying to manipulate clicks, etc. and faking traffic.

We are aware of other techniques that have been manipulating Google suggest, though, and while that doesn't specifically influence rankings, it can lead to people searching for keywords that they wouldn't normally search for.