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:
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:
and drilling into the “get from page URL”:
(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.)
