Salting defeats rainbow tables, not word lists. This sort of attack is largely defeated by basic password complexity and using plenty of rounds of hashing in order to increase the work effort to hash a given size of word list.
So a password with different salts will result in a different hashes. Therefore you have to know the salt in order to guess the password (for offline matching against a dataset of hashed passwords retrieved from a target site). Ideally, every password will have a different salt, and the dataset of salts is stored separately from the dataset of hashes.
Or am I missing something? (Genuine question, because this is not my area of expertise).
Ideally, every password will have a different salt,
More than ideally, the only way it makes any sense at all is if they are different.
As an example:
User: bob password: password1 password hash: 12345
User: sue password: password1 password hash: 12345
with salt that is the same for all users:
User: bob password: password1 salt: 7 password hash: 22345
User: sue password: password1 salt: 7 password hash: 22345
with salt that is different per user
User: bob password: password1 salt: 7 password hash: 22345
User: sue password: password1 salt: 8 password hash: 32345
Per user salt means that an attacker who has stolen the password db can't crack one password and unlock 100 accounts because they all have the same password hash. That is the only point of a salt it serves no other purpose.
I wouldn't say no other purpose. A single common salt can at least protect you from the guy who has a pre-computed lookup table of dictionary words hashed with a standard, unsalted function. (That is, it prevents a zero-computation attack.) Admittedly that doesn't gain you much these days, but it's not "zero benefit".