Balancing SEO vs Convenience: What's Your Take?

Need help App Organization
1

I run a site in the ecommerce space and that typically means two things:

  1. Lots of dynamic content (product information is always changing)
  2. Having good SEO is a big key for growth.

I’m well aware that Bubble isn’t the most SEO-friendly out of the box due to the fact that every element on the page is dynamic (even with a page containing information that never changes).

The Situation
What I’m wanting to do is create different roundup pages for the various categories of products I have. Pages like “Top Selling Monitors of 2022” or “Most Popular Controllers for PS5 Gamers”. The idea would be have a dedicated page with an optimized URL, optimized copy, and then of course display the dynamic products matching the criteria from my database. The page and copy would largely stay the same, but the products within the page will always be changing (think of Amazon’s Best Seller pages as a good example of this).

What makes this complicated is that currently I have about 25 different product categories

Solution A
If my goal was to keep as much inside Bubble as possible, what I could do is create a page inside Bubble called “best-products” and create the template of what the 25 categories would all use. I would then create a dynamic path that would dictate which category would show when loaded. So they would look like:

domain.com/best-products/monitors/
domain.com/best-products/ps5-controllers/
domain.com/best-products/keyboards/
etc.

Once built, everything is within one page on the backend while appearing to have many different pages on the frontend, but it could get messy since every element on the page would have 25 different versions to cycle through depending on the conditions met, which likely means slower loading times.

Solution B
Similar to the solution above, this would still keep everything in bubble but I would literally create 25 different Bubble pages (one for each category of products) which means faster load times and slightly better SEO. The pages themselves would be clean and easy to manage, but if I wanted to do something with design such as adjust the way products are shown, I would need to manually update 25 pages instead of just one.

Solution C (The solution that I fear is the right one)
Keep using Bubble for the e-commerce side and use a 3rd party platform that supports static pages (such as Webflow or Wordpress) for the SEO stuff (blog posts, helpful guides, lists,etc).

The issue with this is assuming I keep my site on the main domain, the “blog” we’ll call it, will sit on a subdomain, which (last I checked) wasn’t as good for SEO as being on the main domain. Moving my Bubble site to the subdomain and the blog to the main domain is an option, but not for my site’s business model.

Perhaps a well optimized static page on a subdomain is better than a dynamic Bubble page on the main domain. But that still leaves me with having two different site experiences for the user. I don’t want the SEO content to feel like it’s on another site. I want to keep the same navigation and everything but perhaps that is just something I’ll need to accept as a tradeoff.

What say the Bubble community? Are there solutions that exist today that would allow me to stick entirely with Bubble and be very SEO friendly?

1 Like
2

Go for Solution B and make the all page content a reusable element. Make the reusable read the product category from page URL or pass a custom state to the reusable on page load.

1 Like
3

I’d still recommend Option A.

Create a data type called Best Sellers. Have a field for category, title tag, meta description, body copy and a ‘list of products’. Plus any other fields that you need to show on the page.

Use a recurring workflow that runs nightly that updates the list of products for each category so that it’s not calculating it on page load. Use a repeating group to display the list so that it lazy loads future cells below the fold.

Should load pretty quick if your page is using the new responsive engine.

2 Likes
4

Oooooh I didn’t even think about utilizing data types for this! Very smart approach!

5

The main issue with Bubble and SEO is that everything (in a dynamic page) that’s relevant to SEO is ALSO dynamic. So, let’s say you have a dynamic page where — AFTER PAGE LOAD — you’re rewriting the meta description — well, did the Googlebot wait around for that?

In modern JS (e.g., React/reactive pages) we see similar issues. But in those types of sites (which at their base are static), we typically serve those metas with the static page. So the bot doesn’t have to wait around for the reactive page.

Dunno what else to say about this except that dynamic Bubble pages (eg, having EXPRESSIONS in your page’s meta stuff) will not in general be read by the Googlebot.

So, whatever results in your metas being served with the page will be superior. Although, also, ANY/ALL of the content on your dynamic pages may be disregarded by the Googlebot because it just didn’t wait around for you to load it.

I’m not being cryptic but trying to succinctly summarize the issue.

2 Likes
6

Yeah - I think Googlebot is better now at waiting for the JavaScript to execute before it reads the HTML but from my experience (and just checked again now), the fields defined at the page level (title, meta description, image, page HTML header etc) are returned in the page source so Googlebot (and other search engine bots) will have no issue finding those.

It would be great if Bubble could at bare minimum return the Current Page’s Thing a part of the initial server response - that would at least give us a lot more of the page to show upfront to the user in many use cases.

3 Likes
7

Yep, that’s basically what I’m referring to. Like, if your meta description comes from current page’s thing’s Description, the bot may or may not read that properly.

1 Like
8

Given that the meta description (among the other page level fields) appears in the initial HTML response and is not loaded client side, then this won’t be an issue. Check one of your pages now - view the page source and check the meta description.

It’s just all other elements on the page that don’t appear in the initial HTML.

3 Likes
9

Ha, if that’s so that’s a big improvement over ye olden days when such expressions were not evaluated server side. Ya learn something new everyday.

2 Likes
10

Ahh I didn’t realize that. That’s good to know. The other “problem” with the data type approach that I’m realizing is keeping the live vs dev databases in sync. I would build out all these “pages” with my special datatype but then when I publish they would be blank because the database doesn’t move over.

I think for the sake of moving fast ahead of the holiday shopping season (which is my busy time) I’m just going to have a dedicated page that dynamically changes to whatever value is passed in the URL. It’s not SEO friendly but it’s WAY faster than whipping up 20 different pages for each category.

The big reusable element that @stefanof mentioned is an interesting approach as well that I’m looking into.

EDIT: I realized what I said about data types wasn’t completely accurate. When writing this I thought moving the database from dev to live was a “all or nothing” kind of thing. I didn’t realize Bubble gave the option to only sync a certain data type and ignore the rest which makes my above concern less relevant.

2 Likes