[UPDATED v2.2.0] 😃 Sudsy Page router for SEO-friendly clean URLs! (by Tech-Tonic)

sad, but thanks :joy:

New and Improved!

Now gets clothes cleaner, teeth whiter, and helps fight mold and mildew!!! :wink:

  • New features!
  • New pricing!
  • New icon!
  • Wow! :grin:

:soap: Squeaky Clean URLs for your Bubble App

Hey all, I’m very pleased to announce the next step in the evolution of Sudsy Page, the premier premium plug-in for SEO-friendly clean URLs.

What It Is

Sudsy Page enables router functionality for friendly URLs and “deep linking” without page reloads. It’s especially well-suited to Single Page Applications but can be used on any page where a friendly “nested” URL structure is desired.

What’s New

This plug-in was created to address the needs of various ongoing internal projects. Since its initial release in March of 2019, opportunities to expand and improve its functionality have been identified and addressed.

Sudsy Page’s feature set now includes…

  • :white_check_mark: URL path parameters core router functionality for friendly URLs.
  • :white_check_mark: Automatic link detection simplifies implementation and enables “crawler-friendly” page content for better SEO.
  • :white_check_mark: [NEW in 2.1.0] Reusable element compatibility for greater flexibility and ease of use.
  • :white_check_mark: [NEW] “Go to URL” action for workflow navigation. Can be used in lieu of or in conjunction with link elements.
  • :white_check_mark: [NEW] Preserve history option when using workflow navigation.
  • :white_check_mark: [NEW] Context awareness for greater flexibility with application logic.
  • :white_check_mark: [NEW] Query string parameters for proper behavior (no page refresh) when QS params are desired - e.g. sorting and filtering. Also enables bookmarking of “search” URLs.
  • :white_check_mark: Hash token detection for enhanced intra-page navigation.
  • :white_check_mark:Set title” action for specifying tab/window name via workflow.


The demos have been updated to showcase some of the new features - e.g. the blog search now uses a button and workflow action instead of a Link element, which results in a nice UX improvement - i.e. just press return after typing search term (no need to click the button).


:warning: PLEASE NOTE: Sudsy Page does not work with Internet Explorer, so if you’re stuck using IE, all I can offer at this time is…well…my condolences. :smirk: (If IE compatibility is important for your project, contact me directly to discuss further.)


Steve @sudsy, how does this work with reusables on the page?

I run a lot of navigation on a single page application between full-page reusables as well as on context menu reusables inside an RG for instance.


Especially with the context menus, it’s not uncommon to have a reusable nested inside another reusable.

Is it possible to make Sudsy work in that scenario?

Love the functionality you are providing here. Amazing job!

@eli, my efforts over the past week have rendered my original reply obsolete, so I’m revising this post to reflect my updated response… In short, Sudsy Page is now fully compatible with reusable elements.

In fact, the demo pages are now running the updated version of the plug-in, so be sure to check them out.

Additionally, the demo pages themselves have been updated with a real-time dashboard of URL data so that you can get a good idea of how the plug-in works…

In addition to the page itself, the plug-in is used in both the header and footer (dashboard) of the demo pages, and those are both reusable elements. Be sure to check out the blog demo in particular, as it uses both workflows and links for navigation.

1 Like

Yes and no. I have both 2nd level reusable navigation elements inside RG’s in a reusable as well as 1st level navigation elements directly inside the reusable.

An example, I have a Job view that is a full page reusable. In the header there are buttons that will take you to the schedule screen, etc that are simple Go to Page workflows.

But on this Job view reusable I also have line items in an RG and inside the cell is a 2nd reusable element with a dropdown menu with navigation elements in it as well.

Currently I use all Navigation workflows but that can easily be changed to external links if needed.

I think I just repeated you and myself there twice but at least it’s all clear as mud now! :laughing:

Ok, thanks for the clarification, @eli. I think I understand.

If you put the Sudsy Page element on the page itself - not inside a reusable element - then it should work. The “router/nav logic” (workflows) must be implemented at the page level as well (not within any reusable element). Sudsy doesn’t care where the Link elements reside; but the workflow logic for the “URL has changed” event must be where the element is located - at the page level in this case. And for a SPA, that makes perfect sense to me.

However, it also means that your reusable elements can’t directly access the plugin functionality (actions or exposed states). That’s a constraint imposed by Bubble’s architecture. But again, that shouldn’t be an issue if the navigation logic is implemented at the page level.
ASIDE: It’s technically possible to use the plugin within a reusable element (I’ve done it), but then you have to use “proxy” custom states or other plugins to pass data between the reusable and the page. It’s doable but generally not necessary or recommended - especially for a SPA.

So as long as the link in the reusable is constructed properly, it will still fire the URL has changed event on the main page?

That makes sense. I’ll just have to think through the structure in detail before retrofitting this.

Thanks for the response!

Exactly! :slightly_smiling_face:

This reply of mine has been rendered obsolete now that Sudsy Page supports reusable elements, as noted in this revised response.

Updated demo pages with real-time data can be found here.


Great wow, thanks! :slightly_smiling_face: I was having to do a whole bunch of intricate extra stuff with zeroqodes router plugin because it doesnt have any compatibility with reusable elements at all. I will be switching everything over to sudsy!

1 Like

Yeah, I found myself implementing “proxy” custom states just to pass plug-in data between the reusable element (header in my case) and the page and figured there had to be a better way. This not only simplifies things, but it makes the plug-in more versatile.

I hope to release the update within a week or so, after I bring the docs up to date.


Very nice!

Sudsy Page v2.1.0 - Reusable Element Compatibility

This update greatly increases the flexibility and ease of use for projects with reusable elements. No need to jump through hoops to access actions or exposed states when implementing workflows. Just add logic wherever it makes most sense - at the page level and/or inside reusable elements.

Features Include

  • :white_check_mark: URL path parameters core router functionality for friendly URLs.
  • :white_check_mark: Automatic link detection simplifies implementation and enables “crawler-friendly” page content for better SEO.
  • :white_check_mark: [NEW in 2.1.0] Reusable element compatibility for greater flexibility and ease of use.
  • :white_check_mark: [NEW in 2.0.0] Go to URL action for workflow navigation. Can be used in lieu of or in conjunction with link elements.
  • :white_check_mark: [NEW in 2.0.0] Preserve history option when using workflow navigation.
  • :white_check_mark: [NEW in 2.0.0] Context awareness for greater flexibility with application logic.
  • :white_check_mark: [NEW in 2.0.0] Query string parameters for proper behavior (no page refresh) when QS params are desired - e.g. sorting and filtering. Also enables bookmarking of “search” URLs.

Demos Updated

The demos have been updated to showcase some of the new functionally. All demo pages make use of multiple reusable elements and show real-time plugin data to provide an overview of the capabilities.

Additionally, the “router” functionality of the quick-start demo has been reworked to employ a simpler and “cleaner” approach to implementing logic. Be sure to check out the quick-start edit mode.

Sample Screenshots

FREE Trial

If you’d like to tinker before you commit, please PM me. I’d be happy to provide temporary access to a private build of the plug-in so that you can determine if it will suit your needs.


Sudsy Page v2.2.0 Now Available (How about a feature with that fix?) :wink:

Version 2.2.0 of Sudsy Page fixes an issue and adds a feature…

  • :wrench: [FIX in 2.2.0] Fixed an issue which prevented initially-hidden reusable elements from responding to the “init” type of URL Has Changed event. Each instance of the plug-in now correctly “sees” the plug-in’s exposed states when the reusable element first appears. (Thanks to @Taiheta for bringing this to my attention.)

  • :white_check_mark: [NEW in 2.2.0] Forward / back navigation actions have been added, enabling you to move forward and back in history an arbitrary number of pages via workflow.

See this post for links to demos and docs.

1 Like

@sudsy as the plugin doesn’t work with internet explorer how does that affect the app when used on internet explorer as a browser?

Does the apps link structure get “lost”, for example if my navigation bar navigates using the URL created with the plugin and a user is on internet explorer do they not get directed to the page?

I’ll have to double check when I’m at my Windows test machine. The bottom line is that IE simply doesn’t support the underlying browser capabilities leveraged by the plug-in.

It might be that the page does load on first visit but that subsequent intra-page navigation is broken. But again, I’ll have to check and will make a note to do so and provide a definitive answer by Monday.

(There appears to be a way to get it to work using some 3rd party libraries, but I doubt it would be worth my while to implement, unless it’s important for some enterprise application and they’re willing to pay for the development.)

1 Like

Just following up on this. It’s exactly as I thought. Basically, the initial page load is fine, but navigation within the page simply won’t work in IE. So for instance, if the page loads from an “external” link - either from offsite or from another page on the site - it works as expected; but links or workflows for navigation within the page will not work in IE.

That said, I’m not sure the existing behavior really matters, as IE is simply not supported, and thus the behavior is “officially” undefined. As such, the existing IE behavior is not guaranteed to remain in future releases. If IE “awareness” is important to your app, then either don’t use this plug-in or do some client-side “sniffing” to determine the browser agent and notify the visitor accordingly - e.g. inform them that IE isn’t supported but MS Edge is and/or provide links to download Firefox, Chrome, etc.

@sudsy thanks for following up…I looked into it and it seems IE is on a downward spiral in terms of percentage of worldwide users; seems like its around only 5%-10% of all users so it may be something that I would just do as you suggest

As it would be better to make the URLs clean for the other 90+% of users out there not on IE.

One question though about something you mentioned

When I am building my app, I never use workflows for navigation to internal pages as I am under the impression they are not picked up by google for site indexing and they don’t provide any assistance with possible SEO benefits. My set for example from the header navigation


Is an “external url”

so, from what you mentioned, would that set up mean it would still work on IE if I am always setting up my link structure this way?

Yeah, that’s my understanding as well and is why I construct my links as you do, and it’s what’s recommended in the Sudsy docs for precisely the reason you cite.

ONLY if those links reside on another page (could be another site or the same site but a different Bubble page). Sudsy has a feature which not only automatically detects hyperlinks (at least those built using Bubble’s Link element as you depict), but also detects whether they refer to the same page on which they reside; and if they do, it does NOT reload the entire page again, which of course (aside from friendly URLs) is one of the main benefits of the plug-in.

If you haven’t already, I encourage you to spend a few minutes perusing the Sudsy demo pages to get a feel for how the plug-in works.

If you have any other questions, let me know.

I am a bit confused about this.

My original concern was about an IE user not being able to navigate through the site because links would be created with the intention of having clean URLs the sudsy plugin provides. So when an IE user is clicking a link the link would essentially be “broken” as they wouldn’t be capable of navigating to the page it is linked to.

From what we have been discussing it seems that is not the case if using a link set up as shown with “external url”

However, the point you make about the link residing on “another page”, perhaps the home page linking to the blog page, I understand to mean, the link would still work.

With that understanding that it would still work, my confusion comes from the idea that you mentioned

wouldn’t this mean that if I was on the blog page and I clicked the link for the blog page, nothing would happen, as the page would not reload again, essentially staying on the same page with the same URL.

If my understanding is correct, wouldn’t this mean that the sudsy plugin does essentially work for IE as long as the link structure is set up as “external url”?