Heya @mward-sudo and sorry to be slow to get back to you!
You nailed it in your diagnosis: you had several different versions of your landing page in our CDN’s cache. How did this happen? Your function, which handles the route for / on your site, seesm to return this cache-control header (and did so as far back as the 14th, based on the age of the data in one node that I examined in depth)
Cache-Control: public, max-age=31536000, s-maxage=31536000
…which means that content would have (without my intervention, wherein I just deleted the entry from every CDN node manually), been stuck in cache for the next year as you’ve specified. This is obviously not what you want - so please, don’t do that again! Your function should return no cache-control response header unless you genuinely want it cached for the length specified, regardless of any new deploys you make (a new production deploy will clear all cache…except for functions or other proxy routes that have told us to hold on to em via a cache-control response header) - as long as you haven’t overridden our defaults as you did here).
Could you tell me if that was an intentional decision by you, and if so, what you were attempting to accomplish (and what you expected our system to do, given that directive?) This article explains why you should basically never need to adjust caching settings on our service: