If you have specific pieces of technology you're working with and want to interview about then take an afternoon and just code up some bizarre snippets to go through with them - add a few mistakes they should be able to catch and just talk through their process.
I honestly don't think opening up a random website and asking about some of the source code is a terrible approach... if you're interviewing someone for writing HTML in the 90's - in the modern world all the JS is minified (and likely generated by a framework), the CSS is absolutely atrocious to read (usually also generated) and the HTML is pretty much irrelevant. Use something that's going to be applicable to candidates to judge their understanding - I've always been fond of short puzzles very much unlike this one (it's way too arcane) in PHP `0x5 &$var=['cow' => 6]['cow']`[1] - just blerbs where you can step through some syntax understanding and problem solving at the same time.
An actually good suggestion is to check out a random (ideally mostly self-contained) file from your codebase from a decade ago and step through what's awful about it - all code bases have these, and they're usually still kicking around as active code in production. At one of my more recent interviews they sent me login.php (the one actually in production, which they knew was broken - they had two developers before me which were really overworked) and just asked me to mark up wrong stuff - I found SQL injections, unbound variables, conditions that would result in invalid HTML and broken forms and some terrible decisions from a readability perspective. I spent... maybe an hour on it.