Basically a client will check 6 HSDirs. It calculates which 6 nodes to check from the .onion address itself.
In the below explanation, Bob is the owner of the hidden service (i.e. the .onion site), and Alice is the person wanting to connect to the hidden service.
Bob wants to advertise his service descriptor - basically a description of his hidden service. He does so by publishing his descriptor to a subset of all HSDirs.
The size of this subset is 6 HSDirs.
He determines which 6 nodes to publish to by using the consensus status document, which he obtains from the Directory Authorities, and uses his .onion address to calculate the descriptor-ids of the 6 HSDirs to use.
[For reference, see section 1.4 - Bob's OP advertises his service descriptor of the specification mentioned above]
Alice fetches Bob's service descriptor from one of these 6 HSDir nodes.
To determine which nodes actually constitute these six, Alice fetches a list of all nodes in the network that have the HSDir flag set. She then calculates a descriptor-id from Bob's .onion address, which she uses to work out which six nodes Bob has published his descriptor to. (There are more details in this part - this is just the crux of what happens.)
If Alice receives a 404 response from any of her attempts to connect to one of these HSDirs, she tries one of the other six nodes.
[For reference, see sections 1.5 - Alice receives a z.onion address and 1.6 - Alice's OP retrieves a service descriptor of the above specification.]