A couple observations:
- I get what you’re doing there. I just looked and was surprised to find that when you assign a type to a page, there’s no option for a source other than the default /uid_of_thing_of_this_type
One could file a bug report (really a request for enhancement) about that, as it seems a fairly natural thing to want to do. (Though it may not be an easy thing for Bubble to implement.)
a. However, I don’t get why people are always trying to work around this. Look at an Airbnb URL: https://www.airbnb.com/rooms/plus/9826723 … it’s just a uid really. As for “field for readable URL” there MAY (may) be some SEO advantages to jamming “holiday home in norwich” or whatever somewhere in the URL (as Bubble enables). It’s not abundantly clear anymore that that is particularly helpful.
- Further to the SEO point, regardless of how “clean” or human-readable or short you make your URLs look, keep in mind that a dynamically generated page will never get discovered by Google and other search bots without a little help. So, regardless of how your URLs are ultimately spelled out, you’re going to want to make a page that’s kind of like a sitemap.
What will be on that page is a repeating group with a link to dynamically populated pages that you want the bots to find. (Like, an RG fed from “listings that are active”. And the cell’s therein would have a link something like “Sunny Surrey Cottage | Holiday Home | Vacation Rental”) where the text is the link and that link goes to Sunny Surrey Cottage’s listing page.
(edit: and obviously, you expose that page in your sitemap. I use a page titled “index_this” and it has all sorts of links to URLs both on my site and URLs about my site that I want to be indexed.)
b. If you want your users to have a sexy URL for purposes of sharing, you might want to implement something like Rebrandly to enable them to have have a link like go.mysite.com/sunny-surrey-cottage
.
Personally, I just don’t have an issue with page types and content being fed by /unique_id. The value of dynamic page title and other metadata (and ease of implementation) far outweighs what I suppose folks feel is the “ugliness” of the URL. (Not to mention that I’m sure that the native Bubble way of associating a thing with a page of type thing is always faster than some sort of intermediate search association. Surely there are advantages to that.)
But bots don’t care what the URL looks like. Also, if you think that your users see “mysite.com/view-listing/unique-id” as different from “mysite.com/view-listing/rentals?ref-some-shorter-than-a-uID-reference-code” I’d refer you to all the posts here in the forums where people (would-be app developers) post pictures of errors from API Connector calls where the error message is telling them exactly and explicitly what is wrong, but they still fail to understand what is wrong.
The point being that nobody reads this stuff. Your users are not going to cleverly construct URLs on their own, so why get hung up on that. Bots don’t care as long as they can get to the content and the speed at which that content is delivered is a factor. So they don’t care about the length or appearance of the URL either, really, just that content gets delivered before they get impatient and say “aw fudge it” (aka, they time out).
A sexy, short, sharable URL is a different problem from URL structure of native URLs in your app. I’m sure some would argue differently, but I would argue they are wrong.
Edit: I guess this is a long way of asking “what is it that you find problematic about Bubble’s native URLs?” Personally, I find it MUCH easier (from both a development and “normal human” perspective) to understand something-something/bubble_unique_id
over something-something/something_else?argument=some_other_type_of_unique_id
.
But I guess I’m just NOT a fan of URL arguments, except when they are expedient and helpful and I’m not sure in this case that they are either.