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.

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.

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.

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).

Shawn124, whenever you move from HTTP to HTTPs, you'll need to set up the 301 permanent redirects for pages on the site only. The other elements, such as images, JavaScript (if they're external files), and .CSS files will need to be changed only in the code so that they reference the new HTTPs URLs, and not HTTP.

If you load an HTTP element (such as an image that uses the full URL in it's reference rather than the image filename only) on an HTTPs URL, then the browser will give you an error.  So generally you need to do two things:

• set up 301 Permanent Redirect for the page URLs.

• search the entire website for all references to HTTP and  change them to HTTPs (unless you're linking out to an external site).

If the site is in WordPress, you can use the Search and Replace plugin to replace it all at once in the database.

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.

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.

John, that's a good question. Depending on the competitiveness of the keyword, I would hesitate to set up a 301 redirect--you still may see ranking changes if you replaced it with a landing page.

I suspect that the reason why it's ranking is because other sites are linking directly to the PDF file, the content. If you were to remove that PDF, they might stop linking to it.

One option would be to edit the PDF file and make that PDF the landing page (in .pdf format), that would be the same URL.

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.

Myles92, recently (in the past few months, I don't recall specifically when) Google did give some recommendations that included having an html sitemap page on your website. For a good user experience, it is recommended that you have a good navigation structure as well as an "html sitemap". The html sitemap page allows users to see the overall structure of the website, and click through to a certain page or section of the site.

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.