Title (for SEO / FB) is not appearing in page conditional properties

mikepost80 · 2020-07-01T16:22:16.845Z

Hi all. I’m trying to figure out how to change the page’s meta tags for OpenGraph (what bubble calls Title (for SEO / FB) and Description (for SEO / FB)) dynamically.

Screen Shot 2020-07-01 at 12.09.10 PM

I have a state variable set up, and want to assign the meta Title to it based on a condition. Only problem is that the “property to change when true” dropdown, is very limited and not displaying Title (for SEO / FB).

Screen Shot 2020-07-01 at 12.08.42 PM676×636 29.8 KB

I’ve seen this displayed in another screenshot in another example in the forum, so I’m not sure if I’m doing anything wrong. But I’m very confused about why I can’t change this property, and would like some insight into this please.

keith · 2020-07-01T16:55:09.054Z

You do this in the settings for the page object itself. Double click on your page object in the editor, and scroll down.

You can build dynamic expressions in the long text fields there, etc.

Note that these options only take effect in paid apps.

mikepost80 · 2020-07-01T17:29:13.252Z

I have a paid app, so that’s a relief.

I still don’t follow though. The 1st screenshot is the pane that appears after I “double click on the page object in the editor”, like you say.

The 2nd screenshot is the same pane (page settings) but under the conditional tab.

keith:

You can build dynamic expressions in the long text fields there, etc.

Does this mean that I don’t need to use the conditional tab at all, and can add the conditions inline the appearance tab?

keith · 2020-07-01T23:00:48.003Z

Sorry, there’s a subtlety here. This only really applies to pages with a data type. In that case the page has an associated Thing (an item of that data type) and you can access the fields of that thing.

This is just an example (not a real page in a real app), but suppose I have a page with a type of Event:

image800×1578 68.2 KB

You’ll get access to Current Page Thing’s various fields in the text boxes.

For a page without a type, you can still fill in dynamic info based on the results of a Search. But of course, that’s only helpful if you there’s some non-ambiguous property you can search for.

Example: Suppose instead of using Bubble’s built-in system of pages having a type, you use a URL parameter to do a lookup. You can do that lookup in these fields using search. So if I have a page that specifies an event via a URL parameter rather than a unique ID, like:

myapp.com/events?event-title=tacofest

Then I could build a dynamic title like:

image1410×1216 92.4 KB

and drilling into the “get from page URL”:

image1414×1218 91.1 KB

(That is, we suck event-title out of the URL param and look for the Event with that title.)

What it sounds like you are trying to do is have your SEO Title change based on some condition. But this isn’t something that Bubble allows.

The basic rationale for that would be that this sort of meta data is in the page HEAD and must be created by the server when sending the page down to the browser.

Now, it is in fact possible to change the HEAD after the page has loaded, but it’s pretty much nonsensical to do that as search engine crawlers don’t really wait around for that sort of stuff to happen. They’re going to scrape the initial content for things like description.

You could play around with attempting this in JavaScript or writing a little plugin to do this (and you’ll find a discussion of doing this sort of thing here) but I kinda sorta doubt you’ll get good results in terms of SEO.

If your goal isn’t SEO but more along the lines of making your page URLs unfurl in some dynamic way when it’s embedded as a link share or whatever, it’s still the same issue. The unfurler isn’t going to execute JS in your page, it’s looking for this info as static values that accompany the page at load time and the “original” values are the ones its going to see.

(Note: I’ve not tested this deeply and so YMMV, but the above is why Bubble doesn’t let you do every type of dynamic expression in these fields, but gives you a more limited palette to work with.)

Note 2: This isn’t just an issue for platforms like Bubble but in other architectures including JAMStack where you’d think that the “static” nature of the pages would ensure that metas are written properly and appear early enough in the page code for crawlers to recognize them. But I’ve worked on React-based sites that use things like the React module Helmet to write metas and have seen issues where the bots just can’t read the headers right, or where the bot just doesn’t wait around long enough for them to appear. (In those cases, one often resorts to creating a cached, pre-rendered version of the pages that are just for bots – and the web server serves those up to bots instead of the JavaScripty version of the page. But you can’t do this in Bubble, of course.)