@pavilaflores Thanks for replying and putting in your thoughts. I will have to politely disagree though, as personally the reply kind of just proves the point I made that you replied to.
As you point out considerations you have regarding the appropriate setup, you make one valid point about performance, which is not really an issue with how we can set things up in the app appropriately, but more or less a Bubble issue. The reason being is that this issue of Page Load Speed has been discussed in the forum for years now.
These page load speeds are well known to Bubble leadership and has been expressed publicly over the past several months as a major focus on the engineering team. Regardless of these page load speed insights from testing tools, the speed doesn’t actually reflect the speed a user sees, and has been reported by others as not a real obstacle for achieving SEO success. There are other Bubble developers who have niche content that gets top ranking results on Google despite the fact that it is a Bubble app.
FYI, first test I did for Page Load Speed Insights on my multilanguage site that uses two different languages on a single page for blog posts, has that same single page used for two different content types (ie: blog category such as home or travel, which show all posts of that category, as well as the actual blog post).
Looking at these numbers, seems to me like Performance is the only metric not performing up to par, and the Best Practices and SEO are right at the top. Accessibility based on my google search indicates it may be an area I can figure out ways to help improve, but also may be partly on Bubble end to improve.
Performance, obviously is a Bubble issue. The linked forum post above regarding performance issues and tests others have done have shown that a blank page in Bubble can show low performance metric.
Yes and No.
If you want the URL to be .com/es/main-content/specific-content/thing, you DO need to have a page called ‘es’ because in Bubble as you know, the first path list item is the page name, so es would be the page name…however, NO, you do not need your URL structure to be .com/es/main-content/specific-content/thing in order to have your language code in the URL…as above posts by me indicate, I set up my URL as such .com/blog/en/specific-content, so my single page of Blog can have more than one language used on it, and when I do that, my performance is not less than 10/100, they are what I posted above.
And No, if you want to have structured content and dynamic meta header/descriptions for more than one ‘content-type’ you can, which again, as posts above by me indicated I have achieved successfully to a degree that my mulit-content types are similar in nature (ie: blog category versus blog article or product search results versus selected product).
Not true.