Before I say anything else, I want to say this - don't waste too much time trying to adhere to a best practice or a prescribed format. Instead, just do whatever lets you capture the requirements and move on. "Individuals and interactions over processes and tools", remember?
That said, a user story that specifies who/what/why is geared towards enterprisy projects, where you have users that have a specific role in the organization ("who"), and want a certain capability ("what") because they need get some work done ("why"). So, a user story is a high-level description, meant to facilitate understanding of why the business needs certain capabilities and how it all fits within the overall business processes and workflows. It's meant to be simple and to the point. It's not a formal requirement specification. Your example is, arguably, somewhat outside that framework, so you probably should adapt the formula to better suit your needs.
Now, clients will often specify requirements in a way that includes some design decisions ("there should be a page with links", instead of "we need a way to provide movie lists"), and if you're not careful about it, you'll put them in the requirements spec, and you'll be bound to those decisions without having evaluated them first. It's your job to consider different options, consult with the client, and make those decisions, not theirs. You may end up doing it in a different way, or you may decide to do it the way they originally described it.
So don't say that the user wants a main page; instead, say "As an anonymous user, I want to be able to access conventional movie lists, because [why - if applicable]", and associate a description with it, explaining what "conventional movie lists" means (or, if you are maintaining a glossary of domain terms, you can place the explanation there: conventional movie lists - New Releases, Top Rated, Recommended Movies, Genres).
Or you could do it in a more granular way, making a separate story for each list, if that makes sense, but again, you'll probably need to document somewhere that these are related, to put things in context.
Or you could just do
"As an anonymous user, I want to be able to access
Top Rated Movies,
because ...", and be done with it.
It probably doesn't really matter - depending on how important it is to understand the intricacies of the workflow of an anonymous user. I'm guessing it's not business-critical. You want to understand enough so that the user has a good experience with the software.