I think you are asking whether you need meta-tests (automated or otherwise). Of course, how do you know that a meta-test is correct? Here is what most developers do: if something feels risky, they test it; otherwise they trust that their code is correct. If something that they trust turns out to have a bug, they try to re-calibrate their judgement. You should do the same thing.
Personally, I would not go through the trouble to mock the HTML. If you have a site you can modify, you might try introducing bugs to see if your tests find them. Of course, you want to introduce realistic bugs, and it may not be easy to decide which bugs are realistic.
We test in order to reduce risk, but testing to excess can be ineffectual and even destructive. If you choose to write automated tests, you are subject to the same decisions that developers are subject to. Most developers do not choose to test every line of code. This is a good thing. Every line of automated test requires additional development effort and additional ongoing maintenance and will not necessarily find more bugs.
There is no hard and fast rule for deciding when to test and when to not test. The decision rests on your own experience, your confidence as a developer, your familiarity with the subject matter, your confidence in the code that you depend on, the maturity of your product, and other factors. Rather than looking for a hard-and-fast rule to follow dogmatically, try something that feels right, pay honest attention to your results, and re-calibrate accordingly.
Here is a rule of thumb that you could try. If testing something requires a huge effort, question your assumptions. You may be trying to test it the wrong way, or the thing you are trying to test may be more complicated than it needs to be, or you might even decide that the risk of it being wrong does not justify the cost of testing it.