You should not use links in the banner because my assumption with the word banner is that you mean a Header which will always be present no matter which ‘view/page’ is displayed by the SPA. This will hit you negatively if you have links to things that are not relevant to the content currently displayed on the screen as the google crawlers will pick it up.
However, you should have links on the page somewhere when they are relevant to the content displayed. So, if you use a floating group that is set to float beneath the page, you can put an RG into that and have a link element inside and link to all related content. It will be picked up by Google and will be ‘visible’ on the page to the crawlers but users will not see it nor will they interact with it. I do this when I have a product page with links to related products but I do not show those related products.
Also, you can make use of the go to page action as you want to for the speed at which it switches between ‘views/pages’ and also have a link element for the SEO benefit of the link. You put a link element into a container, the container is align to parent, then put the element you want the user to interact with to trigger the navigation go to page. Make sure the element the user clicks is above the link and the link is below the element the user clicks…this way the link is there for google crawlers to see, but the user navigates via the go to page workflow action and gets the speed benefit from that.
You can do this with the go to page action. The page itself should not have a content type set, and since it is an SPA, I’d assume you do not have a content type set. Then when using the go to page action we can send text as the data to send and that text is the path or path list if more than one item so you can get those pretty human readable URLs necessary for good SEO. This will not trigger a page reload.
Yes
What I mentioned above.
For all apps
They can still crawl if you provided a site map, but you will not get 100% on SEO best practices via Page Insight scores as links are part of that.
You can, if done properly and the amount of SEO content is not too large. We can use dynamic expressions in the Page Title, Description, Image and Page Header (where we put Structured data). These dynamic expressions can ues :formatted as text operator to create ‘inline conditionals’ to have the appropriate values based on which ‘view/page’ the SPA is displaying.
I have done this in my apps. I have an app that has a single page for Product, which shows the search results of products, a single selected product…additionally it is a multi language site that uses the language parameter as a URL path list item and not a parameter. My URLs can be something like
www.myapp.com/product/en
www.myapp.com/product/en/blue-boots
www.myapp.com/product/fr
www.myapp.com/product/fr/blue-boots
I got the structured data setup for the search results as well as the selected single product for both languages as well as the page title, description and image. All of this works with native Bubble functions. I have from Page Insights 100% on accessibility, 100% on Best Practices and 100% on SEO. Performance is the only area that can be improved that is out of our control as a developer on Bubble since the poor performance is a Bubble issue. The best I’ve achieved in these setups for performance on desktop is around 60%.
One of the more difficult situations with the use of URL path list or path is that Bubble does not URL decode them, so if you are working with a language that gets URL encoded when sent to the URL path list, then you’ll need a plugin to URL decode it. For whatever reason, Bubble felt it only necessary to URL decode parameters.
