The problem with using one password across multiple sites is that all of your accounts can be compromised if even one site leaks your passwords.
Your solution, as stated in the question, attempts to resolve this by using a unique hash on each site as your password. This has some benefits, as it does not require you to actually maintain a password manager (you just need a tool to re-generate the hashes as needed) and you get to keep the simplicity of only having to remember one password for all sites.
However, if we assume that the same attackers who get access to one of your "passwords" can also break that hash, your scheme effectively fails for the same reason a regular shared password would: You're still using the same basic password for each site. Since the attacker, at this point, would also know the salt for the cracked hash, they can easily derive your salt generation process (in your question, it's simply the URL or some component of it). This effectively makes each site's salt "known" to the attacker, and therefore negates their value.
So, how do we patch this bug? Make the salt random, and long. Whether or not you also include the URL as a component is up to you, but here's the problem we run into now: Any salt with a random component that's long enough to add security value will not be human-memorable. (At least, not for non-savants.) Great for protection from attackers. Horrible for usability.
So, what do we do to compensate for that? Maintain a spreadsheet or database with a list of the sites and their associated salts.
Wait... aren't we just back to having a password manager? The only difference here is that you're not actually storing your passwords - you're storing just part of the information needed to re-generate the passwords. Arguably, this is better in the sense that obtaining this data alone isn't enough to re-generate your passwords. But is it really that much worthwhile?