What you're doing now is the best way to do such a thing. We have plans to do better though, to do something like designate a cloud object (such as index.html) to serve as the "face" of any cloud directory, not just the $CloudRootDirectory.

This feature is now live.

(1) if you visit a cloud object directory and do nothing else, it will show a page indicating it's a directory, instead of giving the 500 Internal Server Error page.

(2) inside a cloud object directory, if you create a cloud object named index.html or index.nb, it will be served when the directory URL is accessed. The object can be any type (including an APIFunction or Delayed or FormPage), those are just the magic names to use. You need to additionally assign appropriate permissions to those objects (read for static content, execute for server-side WL content like APIFunction).

In future we will have support for specifying any cloud object, not just ones with magic names, but for now this should serve the purpose.

Example:

dir = CreateDirectory[CloudObject["directory-index"]]
CloudDeploy[ExportForm[Panel[
   Column[{
       Style["How to use a Directory Index in Wolfram CLoud", Large, Bold],
       "",
       "1. If you visit a cloud object directory and do nothing else, it will show a page indicating it's a directory.",
       "2. Inside a cloud object directory, if you create a cloud object named index.html or index.nb, it will be served when the     directory URL is accessed. The object can be any type (including an APIFunction or Delayed or FormPage), those are just the magic names to use. You need to additionally assign appropriate permissions to those objects (read for static content, execute for server-side WL content like APIFunction)."
   }, BaseStyle -> Directive[FontFamily -> "sans-serif"]],
   ImageSize -> 700], "CloudCDF"],
   FileNameJoin[{dir, "index.nb"}],
   Permissions -> "Public"
 ]

Example: https://www.wolframcloud.com/objects/jfklein/directory-index

Any progress? The more I use my cloud resources and share them with others the more others are confused why the cloud doesn't work like a website should. (i.e why they have to go to https://www.wolframcloud.com/objects/b3m2a1.paclets/PacletServer/main.html when experience dictates https://www.wolframcloud.com/objects/b3m2a1.paclets/PacletServer/ should suffice).

Has there been any progress on making the path to webpages less nasty?

That's a rather longer-term thing, along with routing your own domain to content hosted in the wolframcloud.com cloud.

Wonderful! I look forward to that.

I've linked this thread in the ticket where we're implementing this. We'll reply back on this thread when we push this support.

We've had release notes in the past, it may be getting a comeback.

Wonderful! I'm glad this is up. I don't really care about anything other than static HTML as cloud notebooks are still a bit too slow for me and I don't have want to use cloud credits on APIs or Delayed or anything. But I'm glad this works now.

Has there been any progress on making the path to webpages less nasty? I can now use: https://www.wolframcloud.com/objects/b3m2a1/home which is great, but I'd really much rather drop the put my username in the subdomain path. As it stands I don't think anyone not immersed in Wolfram World would by default believe that URL was attached to me.

If you're generating links from within WL, you can use $CloudRootDirectory, which is a cloud object for your account's root.

Then you can build other CloudObjects from that using FileNameJoin:

appRoot = FileNameJoin[{$CloudRootDirectory, "app"}]
assetsDir = FileNameJoin[{appRoot, "assets"}]
iconObj = FileNameJoin[{assetsDir, "logo.png"}]

Once you have the right CloudObject, you can extract the raw URL with First and inject that into HTML or data that will be used later.

Hi Joel,

Any updates on this front?

I think we have entered the medium term, if perhaps the long term.

In particular something like this has a very strong appeal to me

That's unfortunate, but I suppose not entirely surprising. The Mathematica user base has never struck me as particularly developer-y and this is definitely a feature that would appeal to developer types.

I guess it really is time to move on whenever I need to update my sites again. Thanks for all the updates over the past year or so.

Are you sure it's over a year off? I can't see any other free solution to this problem.

It's an order of magnitude estimate.

However, I can say that some of the essential groundwork to support this has taken place in recent weeks, and I'm personally working on part of that in the past few days, and we haven't forgotten about this on our roadmap.