After setting up portal pages to be public, the next step is widgets. Similar to pages, widgets have a checkbox that marks them as public and makes them available on a public portal. While pages that are not public will direct user to an unauthenticated user to a login page, widgets that aren't set up publicly just won't show up. Here are a few public widgets available in the system by default.
You can get caught up when trying to make a widget public. Just because a primary widget is public doesn't account for any embedded widgets that may be used within it. The User Profile widget below is an example of this. By default, the widget itself is public. However, within the Body HTML, there are widgets for included through sp-widget for Team and Preferences. The Team widget is not public while the Preferences one is. Not that you'd want to use User Profile in a public portal, but you can see how this starts to stack up if you need to then make Teams public to make everything work properly.
If you wind up cloning widgets to make something work as public, try to keep them in the scope they originated in. It will introduce Restricted Caller Access rules as the new widget runs and tries to access things it previously was permitted to access.
Finally, as you go through a design, keep in mind to check what widgets are public by default. If you choose to flip them, test them in a PDI prior to including them in the design as there could be unseen blockers when doing the conversion.
