Website Is Down Temporarily
Q. There isn’t really a way to tell Google that the website will be temporarily down without getting dropped out of the index.
- (04:17)Regardless of what is set up on the website, there isn’t really a way to tell Google the website is down only temporarily and will be back live again after some time. For an outage of maybe a day or so, using a 503 results code is a great way to tell Google that it should check back. But after a couple of days, Google thinks it’s a permanent results code, and that the pages are just gone, and they will be dropped from the index. When the pages come back, Google will crawl them again and will try to index them again. But essentially, during that time, Google will probably drop a lot of the pages from the website from the index. There’s a pretty good chance, that it’’ come back in a similar way, but it’s not always guaranteed. So any time there is a longer outage, more than c couple of days, the assumption is that, at least temporarily, there will be really strong fluctuations, and it’s going to take a little bit of time to get back in. it’s not impossible, because these things happen sometimes, but if there’s anything that can be done to avoid this kind of outage, it’s better to try to do that. That could be something like setting up a static version of the website somewhere and just showing that to users for the time being. Especially if it’s being done in a planned way, it’s advised to try to find ways to reduce the outage to less than a day if at all possible.
304 Response Code
Q. Google doesn’t change its crawl rate on the website based on existing 304 pages.
- (11:48) 304 is a response to the “if modified since” requests, where Googlebot tries to see if this page has changed. 304 response code would not apply to the crawl budget side of things. That basically means for Google that it can reuse that request and crawl something else on a website. The other aspect with regard to crawling that specific URL less – that shouldn’t be the case. Google does try to figure out how often pages change and try to recrawl pages based on the assumed page frequency or update frequency that it has. So it’s not so much that particular URL would get crawled less frequently, it’s more that Google understands it’s better how often these pages change. Then based on that. Google can update its refresh crawling a little bit. If most of the pages on the website return 304, Google wouldn’t reduce the crawling rate. It would try to just focus more on the parts where it does see updates happening. So there’s no need to artificially hide the 304s in the hope that it improves the crawling .
301 Redirects
Q. It’s okay to have a lot of 301 redirects on a website.
- (14:57) A huge amount of 301 redirects on a website is perfectly fine and doesn’t do any harm. If there are changes and redirects made on the website it’s fine.
Launching Big Websites
Q. If a huge website for different country version is to be launched, it’s better to start with fewer country and language versions, and expand incrementally from there in case they prove to be working well.
- (15:52) If there’s a huge new website with lots of country and language versions, it’s hard for Google to get through everything. John recommends starting off with a very small number of different countries and language versions and making sure that they’re working well, and then expanding incrementally from there. With regard to international versions, it’s very easy to take a website and, say, just make all English language versions of the website, but it causes so many problems and makes everything in the whole crawling and indexing and ranking cycle so much harder. .
M-dot Website
Q. Even though Google is not supposed to have any problems with M-dot setup, it’s better to go with the responsive setup for mobile versions of websites.
- (30:20) From Google’s point of view, it doesn’t have any problems with M-dot domains in general, in the sense that this is one of the supported formats that it has for mobile websites. John doesn’t recommend the M-dot setup – if there’s a new website being set up, it’s best to avoid that as much as possible and instead use a responsive setup, but it’s something that can work. So if it’s a regular thing on the website that Google is not able to index the mobile content properly, then that would point more at an issue on the website where when mobile Googlebot tries to crawl, it’s not able to access everything as expected. The one thing that throws people off sometimes with M-dot domains is with mobile first indexing, Google switches to the M-dot version as the canonical URL, and it can happen that it shows the M-dot version in the desktop search as well. So there’s also need to watch out for not only redirecting mobile users from the desktop to the mobile version, but also redirecting desktop users from the mobile to the desktop version. That is something that doesn’t happen when having a responsive setup – it’s another reason to go responsive if possible .
rel=”sponsored”, rel=”nofollow
Q. rel=”sponsored” is a recommended setup for affiliate links, but it’s not penalised in case that is not in place
- (31:59) From Google’s point of view, affiliate links fall into that category of something financial attached to the links, so John really strongly recommend to use this setup, But for the most part if it doesn’t come across as selling links, then it’s not going to be the case that Google would manually penalise a website for having affiliate links and not marking them up, he says
CMS Migration
Q. Fluctuations after CMS migration depend on what the migration covered
- (32:45) When moving from one domain to another, it’s very easy for Google to just transfer everything from that domain to the new one. That’s something that can be processed within almost like a week or so in many cases. However, if the internal URLs within the website are changed, then that’s something that does take quite a bit of time, because essentially, Google.can’t just transfer the whole website in one direction. It has to almost reprocess the whole website and understand the context of all of the pages on the website first, and that can take a significant amount of time. During that time, there will almost certainly be fluctuations. The offhand guess is thet there will be at least a month of fluctuations there, perhaps even longer, especially if it’s a bigger change within the website itself. The other thing is that when the CMS is changed, oftentimes things that are associated with the CMS also change, and that includes a lot of things around internal linking, for example, and also the way that the pages are structured in many cases. Changing those things can also result in fluctuations. It can be that the final state is higher or better than it was before, it can also be that the final state is less strong than it was before. So that’s something where changing a CMS and changing all of the internal linking on a website, changing the internal URLs on a website, changing the design of these pages – these are all individual things which can cause fluctuations and can cause drops and perhaps even rises over time. But doing that all together means that it’s going to be messy for a while. Another this to watch out for with this kind of migration is oftentimes there’s embedded content that is not thought about directly because it’s not an HTML page. A really common one is images. If old image URLs are not redirected, then Google has to reprocess them and find them again because it doesn’t have that connection between the old images and the new ones. So if the site was getting a lot of image search traffic, that can also have a significant effect. Setting up those redirects probably still makes sense, even if the website was moved a month ago or so.
Mobile and Desktop Versions
Q. Having the main navigational links a little different on the mobile and desktop versions of the website is a common thing for responsive design and not that big of an issue.
- (39:24) Having the main navigational links on the desktop version of the website different from the mobile version is a fairly common setup for responsive design, in that both variations are visible in the HTML. From that point of view, that is not super problematic, but it’s probably also not very clean because both variations of the UI have to be maintained within the same HTML, rather than there being just one variation in the HTML that is adjusted depending on the viewport size of the device. From that point of view, it should not be penalised, because it’s a very common setup. It’s probably not optimal, but it’s also not something that needs to be fixed right away.
Old Pages
Q. Whether or not some old pages on a website should be deleted is not only a matter of traffic on these pages.
- (41:00) Deleting old blog posts that don’t get any traffic anymore is up to the website’s owner – it’s not something where from an SEO point of view, there would be a significant change unless these are really terrible blog posts. The main thing to watch out for is that just because something doesn’t have a lot of traffic, doesn’t mean that it’s a bad piece of content. It can mean that it’s something that just gets traffic very rarely, maybe once a year. Perhaps it’s something that is very seasonal that overall when looked at from a website point of view, is not very relevant, but it’s relevant, for example, right before Christmas. From that point of view, it’s fine to go through a website and figure out which parts need to be kept and which need to be cleaned out. But just purely looking at traffic for figuring out which parts to clean out is too simplified.
Image URLs
Q. Changing image URLs is fine, as long as it doesn’t interfere with the typically quite long process of Google crawling and indexing it.
- (43:52) Changing image URLs, for example, adding a query string at the end of an image source URL, wouldn’t cause issues with regard to SEO. But with images in general, Google tends to recrawl and reprocess them much less frequently. So that means that if the image URLs linked on the website are changed regularly, Google would have to refind those again and put them in its image index again, and that takes to take a lot longer than with normal HTML pages. From that point of view, if doing that too often can be avoided, it’s recommended to do so. If it’s something that happens very rarely, and where it doesn’t really matter too much how things are processed in image search, because the website doesn’t rely on image search for traffic to the website, in that case, that’s totally fine. The thing to avoid, especially here with the image URLs is embedding something that changes very quickly. So something like a session ID or just always today’s date, because that would probaby change more often than Google would reprocess the image URLs, and then it would never be able to index any of the images for image search.
Google Discover
Q. There are several reasons why a website can suddenly lose traffic coming from Google Discover.
- (45:38) It’s always tricky with Discover because it’s very binary in that either a website gets a lot of traffic or doesn’t get a lot of traffic from Discover. That also means that any changes there tend to be very visible. The main recommendation is not to rely on Google Discover for traffic, but rather to see it as an additional traffic source and not as the main one. When it comes to Discover, there are a few things that play in there. One of them is the core updates. Google recently had a core update, so it’s good to check the blog post that there is about core updates with lots of tips and ideas. The other thing is with Discover in particular – Google has a set of content guidelines that it tries to stick to in an algorithmic way. Depending on the website itself, it might be something where some of these content guidelines are not followed through, and the website is kind of borderline. For example, there is a guideline around clickbait-y titles or clickbait-y content in general, or adult-oriented content. It might be that a website is a kind of borderline with regards to how Google evaluates it. Then it can also happen that the algorithms see that a large part of the website is just clickbait or one or the other categories that Google lists in the content guidelines. Google then will be a lot more conservative with regard to how it shows the website in Discover. .
One-page website
Q. It’s not always important to be authoritative to provide value with a website. .
- (49:40) The question goes back to one of John’s Reddit posts where he allegedly says that 30-page website can’t be authoritative, and the person asking the question wonders what he would approach one-page websites. John says that it’s possible to make good one-page websites and clarifies that by his post he meant that he actually talked about the reasoning that goes “I created 30 blog posts, and they’re really good, and therefore my website should be authoritative”. From his point of view, going off and creating 30 blog posts doesn’t automatically make the website authoritative. Especially for the higher or the more critical topics, it’s something where it’s not right to just create 30 blog posts on a medical topic and claim to be a doctor. That was the direction he headed there. For a lot of websites, it’s not that the author needs to be seen as an authority. He just puts the content out there. If it’s a small business that sells something, there’s no need to be an authority. Especially things like one-page websites are focused on this one thing, and there’s no need to be an authority to do that one thing, for example, to sell an e-book or to give information about opening hours for a business. From that point of view, having a one-page website is perfectly fine. It’s just useful to think where to go from there at some point – maybe creating more pages and trying to find a way to not paint oneself into a corner by having to put everything on one page all the time, but rather expanding whenever that fits.
Sign up for our Webmaster Hangouts today!
