The way NAND flash works is by providing a number of "eraseblocks" - each "eraseblock" has a number of "pages."
For example, there could be 128 Kbyte eraseblocks divided into 64 2 Kbyte pages.
Each page can be written to, changing bits from 1 to 0. If you want to change any bits back from 0 to 1, you have to issue an erase command to the whole eraseblock which resets all bits to 1 (unless the block is worn).
Writing isn't perfect and some bits may fail to change from 1 to 0, or flip by themselves.
What saves the say is this: there is also an "out of band area", or an extra page, per eraseblock. There, ECC data can be written. ECC allows recovery of a certain number of bits depending on the type of ECC (such as Reed Solomon, BCH) and makes it OK for some of the bits to be wrong.
Internally with the raw NAND this is how things work.
But: SD cards do not provide raw NAND access - there's an internal microcontroller inside each SD card that talks to the NAND on behalf of the host. The internal microcontroller is responsible for processing standard SD commands, implementing wear leveling (making sure all pages are written to evenly), and generating the correct ECC codes.
Unfortunately you can't really verify or confirm how an SD card is implementing wear leveling--or it's exact behavior under a given situation--without examining the SD card controller firmware, and this is information difficult to get.
This suggests that SD cards can report an unrecoverable ECC error to the host in response to read commands. I would venture to say that if an SD card is doing this, it means any internal wear leveling/error correction has failed and the card should not be relied on any longer.