Need help with sitemap file

Hi everyone, I wanted to know about the sitemaps once google has successfully saved the sitemaps,

do I need to download the xml file and put it at the bottom?

No, you send the sitemap to Google (you add it in Webmastertools by Google). If you use the dynamic sitemap it updates automatic. See this post: [New Feature] Dynamic Sitemaps - Announcements / New features - Bubble Forum

Edit: If you want to create a manual sitemap file, you can upload it there in the rootfiles. But there is no need for it.

is the idea that there is no need for it because of using the Bubble generated sitemap? I’m looking at creating a sitemap, and can not use the Bubble generated sitemap as I am not using content type on pages for multilanguage site. Trying to figure out what I need to do and not do.

Sorry for my late response. But yes there is no need for it. See

All generated by Bubble. Some page’s don’t have a content-type so there will be only one row. In the products there are all dynamic pages generated (domain + page + slug)

In the tab SEO / Metatags you can activate for what page you want to generate the sitemaps.

Schermafbeelding 2023-10-25 150811

Multi-language sitemaps … interesting problem :thinking:

so no content type of the pages. No use of parameters. Use go to page and data to send as text to form the url path list. Path list item #2 is the language code. In DB saved the links for the different languages onto the data type as a field of ‘sitemap’. CSV export of the data. Copy/Paste into text editor.

It took some time to put all things together for the entire SEO and navigation, but it is so worth it. All pages in all languages is getting picked up properly by Google, including the structured data in the relevant language.

Anybody who says Bubble can not provide good SEO abilities doesn’t know how to do it properly.


smart :clap: :clap: :clap: :slight_smile: Manipulate the path to make Google happy

1 Like

I’m slightly disagreeing with this statement @boston85719, or at least I don’t think it can be done in a way that scales appropriately for complex sites…

We’ve discussed in other threads and there are definitely some limitations when you want to build, for example, a multilingual site hosting content of different nature (different “content-type”) while having a translated URL path with it.

As an example, if you want to have a URL like:


your only choice is to effectively have a Bubble page called “es” in which to display all “main-content /specific-content” entries while playing with visibility conditionals as per what’s in the URL path (and be prepared to see your PageSpeed score to go under 10/100 if building a complex site in this way). If you want to have structured content & dynamic meta header/descriptions, it could potentially be done if you were only displaying content of one single “content-type” nature, but not when having more than one.

The alternative would be to have a Bubble page per “content-type/main-content” category, but if you wanted to have the actual URL translated to the language you are displaying, that would effectively mean having as many Bubble pages per “main-content” category as languages you’re supporting, making it very cumbersome to maintain. So, if you wanted to have:




You’d effectively need to have a Bubble page for “beaches” and another one for “playas” (and additional ones for other languages) and make sure that you keep all content in sync between them at all times.

If you happen to have more “main-content” category pages apart from “beaches”, then you start multiplying this and it grows very quickly …

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

Thanks for your reply @boston85719 . I’m aware of Bubble´s load speeds issues and I also know it’s been addressed by the leadership team in the recent Bubblecon event in NY as a top priority item in their roadmap.

I was getting exactly those Performance metrics before turning my site into a SPA type of web, then it came down to a 7-10 score. It will ultimately depend on what type of site you’re running. Mine requires to load quite a lot of dynamic data (with loads of images) often using “filtered” searches which, as you know, has a toll on performance. Not to mention the fact that Bubble only has servers in US and none in Europe, which sometimes results in waits of more than 10-15 seg for the page to load.

Anyhow, not much we can do on this space (apart form optimising the way we build our sites as much as possible) until Bubble improves things on their end.

You’ve put an example of a page (“blog”) which happens to be named in the same way in multiple languages. In the example I have put, I don’t see how you would achieve the same result without facing the difficulties I’ve mentioned (having separate pages per language so that the actual URL path is in the right language). So, if instead of “blog”, that page is called “beaches”, which translates to “playas” in Spanish, you´d effectively need a page for “beaches” and a page for “playas”.

I’d say “it depends” on how deep your nested subdirectory structure goes and how many of these nested “subdirectories” you want to rank in Google. I had actually done an exercise on the conditionals I’d have to run to be able to have dynamic Meta Header/Descriptions in all my “pages” (sections in SPA terms). It would look like something like this:

If you try to build such expression using “:formatted as text” conditionals, I think we´d both agree it’s just not feasible.

My approach is not for an SPA, and the examples you gave of .com/es/playas-de-arena/espana versus .com/beaches/en/sandy-beaches/spain are not examples of URLs that are possible via an SPA in Bubble because when you alter the index pages URL to append a path it makes the url into .com/index

Sure, if you want to have the different languages for the page name, but that is not necessary, and since it would cause an issue and is not necessary it is avoided to achieve the desired result of having multiple languages on the same page with great on page SEO for each language and each content type. Google does not (as far as I can tell after reading through most of Google pages related to SEO) penalize you for not changing the entire URL into the other language. And in fact most major sites do not do that anyway.

Check here for some examples of top multi language sites, go to a page, change the language and notice how most likely are not changing the page name in the URL to match the language.

Not sure if you were under the impression based on research that you NEEDED to change the page name to reflect the language in order to get good on page SEO scores by Google or just based on an assumption, but for me, when researching, I look to sources (ie: Google) for giving me the playbook of ‘what needs to be done’ then I look at the ‘big players’ on the web (or in the specific industry) and I go through their sites an analyze what they are doing.

Yeah, that is based on your use case, and attempts at making it work. It seems like you are attempting to do it in an SPA, so of course you are going to end up with a mess like that. If you were doing it on a specific page, you’d likely need to revisit how you structure your data or the pages to make it work properly. Most of the time, apps do not need much more than category and subcategory.

No, I don’t agree as that is what I have done in my app to get the desired results. I use the formatted as text operator to create ‘in-line’ conditions…but yes, if I had that mess of conditions in your example image, it would be cumbersome, but not impossible.

I avoid using the filtered operator through techniques that can be found on the forum. When applied correctly it speeds up the search tremendously and allows for better UX and faster performance. One of those techniques is to use text instead of a list field, as I’d imagine the only reason anybody is really using a :filtered operator is to match a list of filters selected to a list field on the data, which doesn’t need to be the only way to achieve the same desired result for a feature of allowing a user to select multiple filters to match against a list of filters on the data entries.

I live in Thailand, there are no Bubble servers here and this does not create much of an issue for me, which might be because I am building my app optimally (at least I believe I am and the results I’m seeing would indicate I am).

In the end, it is fine if you want to disagree conceptually, it is not going to alter my approach that does work and is working as the screen shots from Google tests indicate.

I think you can read all sorts of opinions on this matter. It doesn’t seem to be a major deal breaker when it comes to SEO, but it seems to be a fact that the keywords you use in your URL have some impact (although it can be minimal, don’t know). You can check the link of the first response to that same question here: For SEO, should the path portion of the URL be localized? - Webmasters Stack Exchange

In my case, the name of the top level URL path is a very important keyword with little competition atm, so it makes sense for me to get it translated in case it helps.

All other points, if this topic about having a translated URL wouldn’t matter at all, I’d agree 100% with you. At the end of the day one needs to weigh in the pros and cons of each option and take a decision that works best for him/her, each case is different.

1 Like

This topic was automatically closed after 70 days. New replies are no longer allowed.