When you go to google.com, the certificate under "Subject Public Key Algorithm" shows:
Elliptic Curve Public Key
ANSI X9.62 elliptic curve prime256v1 (aka secp256r1, NIST P-256)
Key size: 256 bits
which apparently is ECDSA. I thought ECDSA is used only for signing/signatures and not for key exchange. What am I missing?
The key doesn't restrict this. Most elliptic-curve keys (leaving out Bernstein) including this one technically can be used for ECDSA signing, ECDH or ECMQV key agreement, or ECIES encryption. The encoding was established by X9.62 because that was the first issued, but the same curves, key values and encoding are used by the other operations. (Many applications also use the point encoding first created by X9.62, but there is some variation there.)
But the cert does. The cert (also) has the KeyUsage extension set to digitalSignature (and the ExtendedKeyUsage extension set to id-kp-serverAuth). This means when used in TLS it can only be used for ECDSA signing to authenticate the server.
TLS/SSL often uses sign-only certs. Most TLS connections nowadays use 'ephemeral' keys (not in a certificate) for key agreement combined with signing by a cert's key (or more exactly by the privatekey matching a publickey cert) for authentication of the server, and optionally but rarely authentication of the client. This provides (Perfect) Forward Secrecy which means that even if a server privatekey is later compromised, recordings of previous sessions cannot be decrypted so their content remains safe (at least from this attack; SSL/TLS only covers transport and never protects against compromise at either endpoint, during or after the session). In the early days of SSL people often didn't bother with PFS, but after Snowden made lots of people aware of mass surveillance programs -- especially non-techie people like managers and bosses and users and customers -- these options became much more widely required or recommended, and used.
For TLS1.0-1.2 (and SSL3, but you should no longer use that because it is broken) key agreement and signing (server authentication) are linked in the ciphersuite: all ciphersuites that use an ECDSA cert for server auth use ECDHE key agreement, and all ciphersuites that use (integer) DSA* cert for server auth use (integer) DHE key agreement; the E in DHE and last E in ECDHE are for ephemeral. Since RSA supports both signing and encryption, an RSA cert key can be used for key transport (encryption) but this is no longer recommended, or it can be used to sign either kind of ephemeral key agreement. (* For hysterical raisins SSL/TLS standards use DSS to mean DSA.) For TLS 1.3 these algorithms are now selected separately, but use of some ephemeral key agreement is practically required on the public net, and use of some signing cert is required nearly always, so they will probably be used in the same combinations as now except RSA-only key encryption is no longer allowed.
See:
https://security.stackexchange.com/questions/20803/how-does-ssl-work (the Great Ursine Epic)
https://security.stackexchange.com/questions/3638/security-of-pki-certificates-certificate-authorities-forward-secrecy
https://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls
https://security.stackexchange.com/questions/35471/is-there-any-particular-reason-to-use-diffie-hellman-over-rsa-for-key-exchange
