I think you need to consider whether you and your manager have the same expectations: the quality of the code, the lifecycle of the products, priorities, etc.
If a site is going to be abandoned or replaced in 6 months or a year, he may not care about HTML validation. The customer pays for "good enough", they don't necessarily pay for "perfect".
I am sympathetic to you wanting to replace spaghetti code with something that's structured, modular, self-documenting, etc. And in the long run, it will be cheaper to build and maintain that kind of code. But if there's not enough money for the short run, there won't be a long run.
You should present your boss with options
"I can spend 3 days to patch this now, but it'll just make the next fix more difficult. The customer is making 3 change requests every month - at this rate, by July of next year the entire site will be unmanageable and it will take 5-10 seconds to load each page. Or I can spend 2 weeks right now to modularize the major sections of the site, and then every change request in the future will only take 2 days, and load time will be less than 3 seconds."
By doing this you've translated your technical concerns into things that he cares about: money, time, and quality.
Then listen to what he says
"The contract is up in 5 months, and we won't renew it because the rates they want to pay are too low. So just do the quick and dirty fix so we can get rid of them."
or
"I expect we'll be slow in February. Can you patch until now, and then do the re-architecting then?"
or
"I hear what you're saying, but that's not our business model. We do quick and cheap, we don't do robust. I know the guy who wrote the code initially made a bunch of mistakes, but he was willing to work 60 hours a week at a low rate, and we only had 3 weeks to get the site up. You'll just have to live with it."
etc.