When your website is too busy due to a large traffic, the best way of redirection is using custom error documents. So, when a user gets 503 error code, the server will redirect visitors to the custom error document page you have defined.
There are different ways for different servers to customize error document pages.
1. For Apache server, add the ...
Many people appear to have this problem on Godaddy hosting and Godaddy have told one complainant this
It is possible that when the error is occurring that it is triggering
the Mod_sec of the hosting account. In the current hosting account
type that you have it isn't possible for us to disable that function
for security reasons. We do have hosting ...
This is unlikely to be "visitors" (real people) but is likely to be automated software testing for vulnerabilities in the software run by your website. I've seen these types of requests for years. The most common for my servers is requests for WordPress administration pages and Microsoft FrontPage extensions.
If you are not running the software, these ...
No, most of the time, checking for mod_rewrite is not necessary. In fact, it is often preferable to remove this check.
If the mod_rewrite directives are required by your site then you should not wrap them in a <IfModule mod_rewrite.c> container. Because if they are required and mod_rewrite is not available then the directives simply fail silently and ...
That appears to be an error message from SiteSpect:
Why does SiteSpect display this timeout message: “We're sorry, the
link that you clicked on could not be served. We are experiencing a
temporary delay due to high volume. Please click RELOAD and try again.
We apologize for the inconvenience.”?
SiteSpect is designed to
proactively close ...
It seems like you're aiming for the second-worst outcome. If you're expecting a spike, you have time to do something:
Implement in-code caching (can be easy, can take a while to get right)
Optimise static files (jpegoptim, optipng, more-css, etc) to reduce bandwidth, speed things up for all users.
Move your static stuff to a CDN to remove those requests ...
Looking into Chrome source code, those numbers 6, 9 or similar are order numbers of enum. In case of 6, this is NETWORK_ERROR, in case of 9 it is SECURITY_ERROR.
Here is source showing that if given error is SERVER_ERROR it will put response code, but if it isn't SERVER_ERROR it will map its error to enum value, and this enum is defined here and the codes ...
It is very common practice to redirect to error pages when putting in a large class of redirects. In addition to wholesale HTTP to HTTPS redirects, this often happens when:
You redirect from naked domain to www (or the other way around)
You redirect from one domain name to another
You redirect an entire directory
Redirecting to a 404 page may not be ideal,...
The TLDR; answer: Send out a 404 header, don't change the url.
The longer answer:
There are more options then you suggest, which I'm not going to list here (because it's not really needed).
The most basic solution is just to serve a 404 header when the page does not exist. The reason for this is simple; This is what visitors expect. You open a URL and ...
the url remains the same, but the page has the status code 404,
This is certainly the preferred option, as Martijn suggests. For a "custom" error page on Apache (ignoring the CMS option for a moment), this could be achieved with the ErrorDocument directive:
ErrorDocument 404 /errors/my404.php
it can be a default server 404 page
Using the default ...
If you still get this problem, make sure...
You don't have switched on "Google Chrome can run in background" option
Go to $sysdrive$\Users\$youraccount$\AppData\Local\Google\Chrome\User Data\Default\Application Cache -> delete files and folders
I had exactly the same issue when using Application Cache on Chrome v38.0.2125.111 m.
Tried several different manifest configs but in the end I simply closed Chrome and reopened it again. Hey presto, issue was gone and cache was working fine!
Hope this helps someone!
Pages that return a 404 not found or 410 Gone code are not indexed by search engines.
From Google webmasters center:
This HTTP response code clearly tells both browsers and search engines
that the page doesn’t exist. As a result, the content of the page (if
any) won’t be crawled or indexed by search engines.
We recommend that you always return a ...
The best solution to ensure they don't get indexed is by adding
<meta name="robots" content="noindex">
If Google only encounters the pages as error pages it shouldn't index them, however, potentially if they were accessible through the sitemap or had inbound links, they could be indexed. It's advisable to just add the noindex tag to prevent this.
I've been able to reset a lot of my site's values using appcmd, but I had to dig into specific configurations I wanted to change, which I'll describe a bit below. I know for sure that this works with IIS 7, but I'm not 100% certain whether it passed on to 7.5 so YMMV.
appcmd isn't in my cmd path on any of my installations (though these machines are 2k8sp2) -...
Cloudfront is Amazon's Content Delivery Network. This answer should help explain the messages in the log: https://stackoverflow.com/questions/9197918/why-is-cloudfront-loading-scripts-in-my-web-app-i-dont-use-it.
The conclusion is
As mentioned upfront already, I share the initial conclusion that the
code itself is probably harmless, although the ...
OK, I found the problem.
My site uses SPIP3 which has a bug when the sitemap is GET by googlebot
Just fix config/ecran_securite.php by adding an @ before array_shift() somewhere near to the end of file.
(edit) I forgot: thanks to http://web-sniffer.net/ too. Just set the user agent to "Googlebot"...
I would say yes, simply because there isn't any need for dynamic error pages. For example: If your database is down or under pressure, it is unlikely that you will want your error pages to be attempting database connections. Likewise, if your server is under pressure, you don't want your error pages to be carrying out any server-side processing. All-in-all, ...
This really depends on the error being served. For a 404 error, there would be no reason that there are any issues with the server - meaning all the php stuff should be working find. But if you have a 500 there may be an issue with the server, preventing php from running. This really depends on your tolerance for risk.
In short, yes.
But, good HTML does not automatically mean you will get more traffic, so the fact that you have not seen an increase may not have anything to do with your HTML.
To your questions about HTML, some ways that bad HTML can affect your search engine indexing and traffic.
Sign-up for Google Webmaster tools, go to Search Appearance, then to HTML ...
There are things you can do at a number of levels:
Network Hardware: Install a load-balancer, with addition servers behind it. This will allow you to run your existing set-up fairly easily, but will probably cost quite a lot of money to setup in the time frame you have (depending on your hosting providers support levels)
Virtual Hardware: ...
Your request body is very large. If I'm correct, your request body is at least 10.4 KB in size because of all those fields that begin with chk and that have a value of at least 5 characters. That makes 10 characters (including equals and a one-digit chk number). Multiply 10 by 1024 fields crafted this way and you get 10.2 KB request size minimum.
It happens because the Google server that is used by Google Webmaster Tools is not necessary located in Luxemburg because based on your research, the Google.com's server is there.
Google uses many servers around the world and it is almost impossible to know from which one you will be crawled every time.
Furthermore to your question, I really think is a ...
An example taken from the jQuery site itself is:
The problem isn't on Google's end, it is on your end. Your HTTPS is fine:
$ curl --head https://www.qcandles.com/robots.txt
HTTP/1.1 200 OK
However your HTTP to HTTPS redirect is broken for deep links:
$ curl --head http://www.qcandles.com/robots.txt
HTTP/1.1 301 Moved Permanently
The screenshots indicate you are looking at the http and non www version of your site.
The home page inspection report indicates that the home page for that site (http without www) is redirecting to the https with www version . https://www. and that it is not indexed because of that. That's from the "page with redirect" statement and what Google says it has ...
If this error affects any of the processes, the crawlers may not favour your website over others.
Even after fixing errors, there should be some things to be kept in mind while ...
Have you tried contacting Tumblr with your username then contacting your vendor that you bought the domain from? Could be a server related issue on Tumblr's side, same thing happens with Twitter occasionally.
Googlebot uses code that is custom to Google for converting the HTML pages into text. Google has not released this code, and nobody is sure exactly what they do in all cases.
Usually Googlebot just sees the page source and removes the HTML tags. There are many programs that can download the source code of a page (even masquerading as the Googlebot user ...
Make sure that you uploaded the right html file. If you have multiple google accounts upload file for that particular account.
You can also try alternative verifying methods like TXT, CNAME Etc.