If the captive portal auto detection doesn't work, and hitting a common domain (like google.com), try a domain you don't normally visit (and hence won't be cached anywhere). Try borg.org, for example.
If that still doesn't get you the landing page, it's time for extreme measures. You can get more information about the DHCP config it got with
ipconfig getpacket en0 (or en1, or whatever the Wi-Fi interface is); look especially at the "server_identifier" (the server that sent the info), "router", and "domain_name_server" lines. Try hitting those in your browser and see if any get you a landing page.
Still nothing? Next try
host www.cnn.com x.x.x.x where x.x.x.x is the domain name server (if there are several, try with each). If you get back any IPs that weren't already on the list, try them in a browser.
BTW, the reason this sometimes doesn't work automatically is basically that it's all highly nonstandard. Captive portals are a hack that someone came up with to control access to a wireless network in a way that the standards didn't handle. Lots of other manufacturers copied the idea, but everyone did it a little differently, and it hijacked real web pages in the browser, and was generally a mess. So Apple built a system into macOS that'd try to detect captive portals and display the landing page automatically, in a way that didn't hijack the browser... but since there are so many variants on the idea, it's hard to build a system that handles them all. And then sometimes the local network admin sets things up weirdly, and... basically, it's a hack to get around another hack, and as a result there are a lot of ways for it to fail. Frankly, I'm kind of amazed it works as often as it does.