Subject identification in SSL/TLS server certificate is DNS name(s) usually and/or IP address(es) rarely, which are matched against the requested URL. Neither of these determines location. EV certificates must contain some physical location information verified by the CA, and other certs may, which the browser cannot further check; some browsers display some EV info, which the user could check against his/her knowledge of the organization/person that should be running the website.
The validity period is compared to the current time. If a client device has a wrong clock, or none, it can be tricked by a server using an expired cert for a stolen or broken key.
BasicConstraints, KeyUsage and ExtendedKeyUsage extensions if present (and at least the first two should be) are checked to make sure the cert is suitable for the SSL/TLS protocol in general and for the negotiated key exchange. Policies if present could be checked against configuration (or user entry) what policies are required, acceptable, or prohibited, but I don't think anyone does.
The Issuer name, and AuthorityKeyIdentifier (AKI) extension if present, are used to obtain (select) the parent CA public key used to verify the cert, so if they are wrong, the signature cannot be and is not verified. This repeats up the chain and validity, BC, KU, EKU are also checked up the chain to make sure each cert is suitable to be an issuer (CA).
All certs (including chain) must also be checked for revocation. This is done using information outside the cert(s), namely a CRL signed by the CA, or an OCSP response signed by the CA or other trusted party. Nowadays OCSP responses are usually included in the SSL/TLS handshake by the server (called stapling); if not the browser can fetch them using the cert(s) CRL Distribution Point and/or Authority Information Access extensions. This can provide an indirect check; if you get valid (signed) data from CRLDP and/or AIA.ocsp it establishes those values are right, but if you have trouble communicating it doesn't necessarily mean they're wrong, and if you don't even try (because of stapling) then obviously you don't know at all.
The Public Key in the cert cannot be directly checked; the main point of PKI is for the relier (browser) to securely obtain the public key which it does not already have. The SSL/TLS handshake does confirm that the server has (and uses) the private key corresponding to the public key in the cert; the cryptographic mechanism for this varies depending on the key exchange negotiated.