@costin offers good advice in his comment.
This is a deep topic where any "quick answer" will, by necessity, leave out important details for your particular use case. That's why you see lots of advice of the forms you cite (e.g. too general "use strong ciphers," or overly specific "paste this string" with no explanations).
That said, I'll offer my own incomplete answer from a fairly basic, practical standpoint. ;-)
For public web apps, where you don't control the end user connection, disable SSL 3.0 and lower - see recent POODLE attack mitigation see POODLE PDF .
There are some academic weaknesses in TLS 1.0 as well, but it may be the best some browsers can handle. Still, most of the recommends say to go to later versions of TLS if you can.
A while back, RC4 was recommended as a mitigation for the BEAST attack, but it has it's own known weaknesses, and that advice is now also considered out of date.
A whole class of "oracle padding attacks" have been launched against various Chained-Block-Cipher (CBC) suites, so in general those are out of favor as well.
RFC 4492 defines Elliptic Curve Ciphers (ECC) and TLS can use Elliptic Curve Diffie-Hellman (ECDH) which seems to be gaining popularity.
Yes, there are speed/strength/memory/performance trade-offs with ciphers which you may have to deal with if you run a high-volume web application for an enterprise, but for many single-server websites, those kind of trade-offs don't really enter in to it.
A good starting point for a simple health check is to analyze your server with SSLlabs and fix anything they mark you down for. No, it isn't perfect, nor will it replace good knowledge of the security trade-offs you may be asked to make, but it will make you more secure (in a practical sense) than most of the other sites out there.