Is using the same HTTPS cipher suite as Google a good idea?

Question

I'm searching for a cipher suite for my HTTPS website, running on the Apache 2 web server, that would offer a good compromise between compatibility with users and security. One idea I had was to simply using the same cipher suite that Google uses, i.e.:

Accepted  TLSv1  256 bits  ECDHE-RSA-AES256-SHA
Accepted  TLSv1  256 bits  AES256-SHA
Accepted  TLSv1  128 bits  ECDHE-RSA-AES128-SHA
Accepted  TLSv1  128 bits  AES128-SHA
Accepted  TLSv1  112 bits  DES-CBC3-SHA
Accepted  TLS11  256 bits  ECDHE-RSA-AES256-SHA
Accepted  TLS11  256 bits  AES256-SHA
Accepted  TLS11  128 bits  ECDHE-RSA-AES128-SHA
Accepted  TLS11  128 bits  AES128-SHA
Accepted  TLS11  112 bits  DES-CBC3-SHA
Accepted  TLS12  256 bits  ECDHE-RSA-AES256-GCM-SHA384
Accepted  TLS12  256 bits  ECDHE-RSA-AES256-SHA384
Accepted  TLS12  256 bits  ECDHE-RSA-AES256-SHA
Accepted  TLS12  256 bits  AES256-GCM-SHA384
Accepted  TLS12  256 bits  AES256-SHA256
Accepted  TLS12  256 bits  AES256-SHA
Accepted  TLS12  128 bits  ECDHE-RSA-AES128-GCM-SHA256
Accepted  TLS12  128 bits  ECDHE-RSA-AES128-SHA256
Accepted  TLS12  128 bits  ECDHE-RSA-AES128-SHA
Accepted  TLS12  128 bits  AES128-GCM-SHA256
Accepted  TLS12  128 bits  AES128-SHA256
Accepted  TLS12  128 bits  AES128-SHA
Accepted  TLS12  112 bits  DES-CBC3-SHA

Presumably, Google has chosen their cipher suite to be compatible with most people's browsers, while also being very secure, so it seems that this should be a good choice for a cipher suite in general. But since I'm only running a small website, I'm not entirely convinced that what's good for Google is also good for me. So my questions would be:

1. Are there any ciphers in the suite above that I should not use? And if so, why?
2. Are there any other ciphers that I really should allow, even though Google doesn't?

Answer 1

But since I'm only running a small website, I'm not entirely convinced that what's good for Google is also good for me.

You're right with this assessment. Google has far more ressources for this than you probably have and this is why they can do things like roll-out ChaCha20-Poly1305 before it's standardized or the new post-quantum key exchange they're using, especially since they largely control development of Chrome which has an insanely large userbase.

Are there any other ciphers that I really should allow, even though Google doesn't?

Yes.
For some reason, Google offers only ECDHE and (static) RSA cipher suites. While they reach the most people with this, you probably don't need to reach those ancient browser who don't understand either DHE or ECDHE (it's 2016, come on!). So the recommendation here would be to add the DHE variants of the cipher suites (although with lower priority than the ECDHE counter-parts).
Additionally you should consider adding (the now standardized) ChaCha20-Poly1305 cipher suite(s) into that list if supported by your TLS implementation, because of the high perfomance on mobile platforms.
Note though: If you can, disable parameter (as in the private key) re-use with the (EC)DHE cipher suites and generate your own DH parameters (and use them) once (using OpenSSL or something like that).

Are there any ciphers in the suite above that I should not use? And if so, why?

Yes.
All the cipher suites that lack "ECDHE" or "DHE" in their name should be gone. Those are a) removed from TLS v1.3 anyways and b) if your server key ever gets leaked (heartbleed anyone?) an attacker can decrypt all the traffic that has ever been recorded while this key and these cipher suites have been used. This doesn't happen with the (EC)DHE suites and the property for them is called "forward secrecy".
Additionally you can (and should) drop the 3DES cipher suites because you don't need the backwards compatibility they provide (probably) and because they have quite a small block size, making them vulnerable to attacks like Sweet32.