Expanding on the very limited dynamic data for SEO descriptions

Hi All,

Currently the ‘Page title’ in the Bubble editor on a page offers the full choices when using dynamic data, perfect - as shown below on a dynamic page:
image

Now with regards to the SEO description these dynamic values become limited to just the ‘Current user’ and ‘App text’ which unfortunately aren’t helpful when using a dynamic page such as listing, product, user…

image

Unfortunately copying an expression and pasting in doesn’t provide an easter egg :wink:
image
image

I know it’s possible to execute Javascript into a workflow then to insert, but ideally native support within the Bubble interface would be much preferred - (referring to this post [SOLVED] How to use dynamic data for Page Title and Description? - #2 by asher)

Please @emmanuel could this be addressed in the near future, I feel dynamic pages are lacking SEO support and this would really help out. Thanks.

Best,
Luke.

1 Like

Folks seem to misunderstand this. If the page has a type, you can do all the metadata stuff you’d want to do. I explain the “why” of it (somewhat poorly) here:

I do exactly this with my listing and calendar pages in my app. Remember also that, just because the page has a type doesn’t mean u can’t have other types of data on the page. You can have groups that represent sections that host different data objects of course.

Note also that once your page has a type you are connected to other important things as well. For example, if you wanted your listing page title or metadata to include the host’s first name, like:

“Happy Villa Vacation Rental, Hosted by John S.”

That’s something like:

Current page listing’s Name, Hosted by Current Page listing’s Creator’s First Name Current Page listing’s Creator’s Last Name:truncated to…

Of course one must also be mindful of one’s privacy rules, etc., blah, blah, blah.

2 Likes

Hey @keith

Sorry, somehow missed your reply here, my bad, thanks for the response.

I know that changing the ‘Page type’ to say in my case ‘Listing’ then does allow for the ‘Current page Listing’ option as the below
image

But with my setup its not quite ideal - here is why.

I don’t really want to generate and use URL’s like these
image

So on the link from the search page I have the workflow when a certain listing is clicked
image

Then on the dynamic page of the rental listing, I have a master group with the data source and type being pulled through the URL parameter as below

In order to achieve a much cleaner URL in a query.
image

Therefore I’d really love if the dynamic data on the Title and Description for SEO purposes was a lot more varied. With that said, please point out any issues with my setup, yet to deploy so there may something I’m missing Keith. Cheers.

A couple observations:

  1. 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.

  1. 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.

2 Likes

Just thought I’d re-bump this thread, as I’ve noticed in the past months people have asked about how to generate a cleaner URL without setting the page data type/content. @keith has done a great job in really detailing these workarounds and setup required.
Users have suggested using the ‘Get data from page URL’ and then reading the path within the set URL. This is a clever workaround and indeed works (improved upon reading the parameter) - but for a frontend page, that you’d want indexed by search engines, its not really viable, as the SEO meta data cannot be set.

This is why having access on the pages SEO title and description, it would be great to have access to ‘Do a search for’ and then at least we can map the path with the data search to pull off specific text - fingers crossed for future implementation :+1:.

1 Like

You should note that the method I show in the “gibu” demo app DOES use a typed page. So these pages are indexable.

EDIT: I should note that, if you want the /username to be the version of the URL to appear in the index, you should set the canonical URL that way.

The bigger issue with dynamic pages and indexing is the time it takes for the page to render. The Googlebot in particular does not wait around for a great deal of time.

Dynamic pages that have complex conditions or elements that load slowly can lead to indexed results that are not what you’d expect. Testing in Search Console is essential.

2 Likes

And actually, @luke2, in thinking about this more, the “reason” that more complex expressions are not allowed in the SEO type fields may be the speed issue. :thinking:

Ah yes fair point, didn’t realise your demo used a page data type, well played, it works pretty well at masking the URL quite quickly.

I’ve seen another method used which is a very simplified version without the Browser plugin, which simple uses a ‘go to external site’ combined with the ‘get data from page URL’ via path, so no set data type.

But yes, I think your right, speed is what it comes down to, with regards to assembling the <head> content of the page, its just not quick enough to pull the data in yet. As much as I’d like a cleaner URL, I’m not taking the possible risk of bots bouncing off the page or not properly indexing meta content, so will be using the ugly version till I can get an upgrade :wink:

I’m also stuck on this problem, the client wants to use clean urls that I’ve implemented using the “get from URL” work around. However, they also want the correct meta descriptions to show up in google, very understandable request imo.
I understand the issue being the speed of pulling that data in, however, how is this different than the “Page Thing”? That data are still being pulled from the DB, even if it was a list of aliases (URL = Unique ID) to propagate the data needed?

Hey @josh13

So recently Bubble has improved the SEO title and SEO description properties for pages, they’ve now enabled the ability to ‘Do a search for’ to find an object and do the normal things like filtering and merging searches. Anyhow, with this addition its now possible to use clean displaying URL’s and get data for SEO purposes. With that said, you’ll need to be on a paid plan (any e.g. Personal) for it to actual render in the page source.

I’ve setup a very quick demo here of how this works in principle and you can access the editor too:
Preview

Editor

So currently setting a page thing (type of content) will restrict the display URL, usually resulting in the unique ID that Bubble generates on entries. Using this method does give you direct access to the object for the SEO page data. This URL can be slightly adapted e.g. add fields of an object to be displayed at the end of the URL string, but you’ll still have the super long ID attached.

This method of getting the page path (or can be done with URL parameter and even segmented URL paths) will allow for clean URL’s that can be specified, but be sure these are unique in the search (no dup alias’s with the same string). They can be set to whatever your preference is, but be sure to also separate spaces with either ‘_’ or ‘-’ to avoid space corrections in URLs (unless you use the join operation).

The preview above won’t actually display the correct SEO title and description due to the app not being on a paid plan, but this should correctly render in practice.

Now in reality with 100s or 1,000s+ of entries within the DB doing a search across all these entries and filtering could be slow going (could also depend on the apps plan), so whether search engines wait for the request to complete I’m not too sure and would need to be tested at scale. You essentially have to do 2 single searches for the title and description. I’ve suggested to Bubble about also allowing to be able to select the objects on page (in this case it would be the main var object, like in the ‘Page title’ in screenshot), so you could actually refer straight to the data source, therefore just the single initial request is made, hopefully cutting time down for the data to render and pull in the data.

I’d suggest on the data objects to create 3 unique fields to cater for this method. 1 is the actual alias to refer to in the clean URL and the other 2 are text fields dedicated to the SEO title and description (rather than using other field data an manipulating e.g. trimmed, extract with regex).

So I think the answer is, yes you can utilise clean URLs now and pull in SEO data related to an object entry, however, with big data I’m not sure the implication this could have on search engines, something untested and depends on the data set being used for, the sole purpose e.g. blog

Hope this helps.

Luke.

4 Likes

I’ve changed the post topic to ‘Idea implemented’ as dynamic searches are now supported on pages. But as suggested in the post above, it would be nice in the future the SEO title and description could pull in page element objects that have a valid data source, in efforts to speed up requests. Cheers.

3 Likes

Hey Luke,

Thanks for the detailed write up, I’ve been testing the ‘Do a Search for’ without much success for the descriptions, however, I have been successful at pulling the title from a page custom state I load in at page load. so you don’t actually have to use a ‘Do a Search For’ for the title, just have it run as the first workflow on page load to store the thing in a state and call to it in the page SEO settings. I don’t know why this works but it does, only for the Title.

I think I might just be tasking the system too much by the time it gets to the description search (I’m also running a regex find and replace on the Url to extract the last portion(.*[\/]) ) so I’m sure that’s just slowing it down a little more.

I’m going to try creating a new DB that has nothing but URL tags and corresponding SEO data to see if that simplifies the search enough for it to pull the info quick enough.

Thanks,
-Josh M.

**** EDIT ***

Got this working, I realized I was copying and pasting the my URL find and replace when I just needed to use the “Get data from Path”. Works now! Thanks Luke!

2 Likes

May I ask why my “Do a research for” dynamic Title and Description do not read? Is that because ":formatted as text " causing too much resource?


Sorry, late to the party of this discussion:

@Keith Concerning your comments here: Expanding on the very limited dynamic data for SEO descriptions - #4 by keith

I like your idea to have a page called “Index_This”. Can you elaborate a bit more? Following questions from my side:

  • Do I need to “Disallow: /index_this” in the robots.txt in order to avoid that a bot crawls the page index_this for any other purpose than the sitemap? Because I assume users are not supposed to be pointed to the page index_this in the search results.
  • Does it bring any additional benefit to refer in the robots.txt explicitly to the sitemap (like this: “Sitemap: https://your-bubble-app.com/index_this”)
  • Besides dynamically setting the page-title, seo-title and seo-description - especially in SPAs - does this solve finally the pain of getting dynamically generated content indexed?

Example: I navigate on index-level with parameters (view=courses, view= dashboard, view=blog) because I wanted to avoid to have /index/courses etc. In my case view=blog contains an overview about all blogposts and when a user clicks on a specific post I navigate to an actual page called “blog” and send a slug to the page. On Page-Load I cache the whole posts table, save the SEO stuff to the DB and reference it dynamically in the Page settings.

So speaking from the perspective from a crawling bot - if I understand it correctly - it would only see an empty container on page “blog” but not my 500 individual posts filtered down to a single post in that container, right?

So this is why it is so crucial to expose every url behind blog/ in “index_this” and make sure that this page is indexed, right?

I am asking this, because the documentation about sitemap specifically on bubble is a bit limited, but will do some more research on this topic now.

Cheers,
Tobias