Website

HighLevel’s Reviews widget outputs AggregateRating structured data on website pages, but the markup is missing required fields, causing Google’s Rich Results Test to flag a critical issue: “Either ratingCount or reviewCount should be specified.” Where the problem occurs Websites (Website Builder) → Pages using the Reviews widget (Structured data / Rich Snippets output in the page source) What happens now When a page includes the Reviews widget, HighLevel injects Review/AggregateRating schema in the page code. Google’s Rich Results Test flags the AggregateRating as invalid/critical because neither ratingCount nor reviewCount is included, even though ratingValue is present (ex: 5.00). Result: pages get structured data warnings that can reduce eligibility or trust for review rich results, and it creates confusion for agencies trying to deliver “SEO-clean” sites. What should happen instead HighLevel should output valid AggregateRating structured data by including at least one of the required properties: ratingCount or reviewCount …and ensure the output aligns with Schema.org + Google’s structured data expectations. Real-world use case We build client sites in HighLevel and often add the Reviews widget to service pages/homepages for social proof. When we run QA using Google Rich Results Test or Search Console, we see a critical structured data issue on pages that otherwise pass. This creates: extra client support + explanations (“why is Google saying this is broken?”) potential reduced SEO performance/eligibility for review enhancements additional dev time to troubleshoot something generated by the platform Current workaround (if any) Avoid using the Reviews widget on SEO-critical pages, or Use a custom-coded schema injection (manual JSON-LD) and attempt to suppress/ignore the widget’s output (not always clean/easy), or Accept the error and ship anyway (not ideal for agencies and SEO deliverables) Suggested fix or enhancement Option A (Best): Update the Reviews widget schema generator to always include: reviewCount (total number of reviews displayed/available) and/or ratingCount (total rating count) …and ensure the values are accurate. Option B: If accurate counts are not available in some cases, provide a setting/toggle: “Enable Review Schema” (on/off) so users can disable invalid schema rather than being forced into a critical error. Option C: Output the schema as JSON-LD in a single, clean block (if not already), ensuring required properties are present for AggregateRating.

Need the GHL team to have a look at this !! ;) Hi guys ! I looked on different websites created with ghl and ALL OF THEM have this loading time between a font (which we don't want) and the font we choose (in the site builder). I don't see this on any other CMS (wordpress, webflow, wix,...). The websites created by them are all smooth and do not have any fonts to load. (or don't take time to load so we don't see it) The problem ? 1) The font takes 2/3/4 seconds to load every time we open a new page of the website. 2) Sometimes (it depends on the browser and the place from which the website is opened... Google, safari, google maps, firefox,...), and most of the time on mobile view (which is most important), the font loads perfectly on the first page but when we open another page it does not load at all and we therefore end up with a site which has a completely different font. We need to refresh the page for the font to load (which website visitors don't do). (see video) IN SUMMARY, the font takes a few seconds to download or simply does not download. which ruins the user experience on the beautiful website we are able to create on ghl ;) EDIT: I think I found where the problem comes from. This is a FONTAWESOME link called "fa-brands-400.woff2" and "fa-solid-900.woff2". (see screenshot) I don't know if they are necessary for websites. but why doesn't the ghl team just remove this font (link) on all the website? It will be much smoother to have only 1 font loading than to have a first font and then the second one loading...

No client knows what their SMS daily limits - or if hitting SEND one more time will RESTRICT their account. This is especially painful if the location is sending a campaign. RECOMMENDATION 1: Warn the user that the action is above their current tier. Recommend they reach out to the agency or schedule over longer period of time. 2: Quietly notify the Agency so they can PROACTIVELY help the user. Check out this scenario. *Keep in mind, this follows all best practices GHL provides in SMS v2 ramp up model for every. single. level. WHO 2 year client w/ 200 contacts Sms usage 10-60% daily limit WHAT Big yearly event coming up, so they create a campaign NO WARNING that hitting send will send them to temporary jail 24hr RESTRICTION & WARNING EMAIL FROM GHL GHL DND'd 100 accounts Agency needs to quickly react to client Agency needs to upgrade SMS Tier Agency needs un-DND the contacts that were blocked from this specific campaign (good luck) Agency needs to coordinate with Client to identify contacts and resend the failed 100 sms texts WHY No really... why?! The current ramp up model LITERALLY makes you hit a 24hr ban before you can use the next tier, potentially requires a ton of hand-holding from the agency, and has clients loose faith in this platform. This idea ALSO rocks. I'd hope for both, but prefer Kalel V's suggestion. https://ideas.gohighlevel.com/crm/p/lc-ramp-up-model-v2 Honorable mention: https://ideas.gohighlevel.com/lcphonesystem/p/sms-monthly-limits

The current website builder's animation feature fails to properly animate initial elements like headlines and subheadings, making them briefly appear before disappearing and then animating. This looks bad, so please make the elements remain hidden until animation triggers, preventing pre-visibility and ensuring smooth transitions when loading the web page

Cloudflare is currently delivering 500 Internal Server errors. Even the HighLevel status page is failing (see pic)

Before LevelUp (2025), you used to be able to remove one of the size requirements (height/width) and the image would self-adjust to show it correctly. Since LevelUp, it forces a size for both height and width, distorting the image unless I guess the correct size for both on all images. Please fix this as soon as possible.

I keep experiencing several issues with the margins and padding of sections. Bug 1: Inconsistencies between the website builder and external preview. For example, see the difference in the spacing between the website builder (Picture 1) versus when I preview the website (Picture 2). Both on the same screen, same window size. I have checked the padding and margins of every single element inside these containers and they are all set to zero. This is not the first time this has happened either. Bug 2: Sometimes my rows randomly align to the left instead of center, and no matter what I do, I cannot get them to re-center. Again, all the padding and margins are set to zero. I end up having to add a new row and move all the contents into it and just pray it doesn't happen again. Bug 3: After adjusting the padding/margins of an element, when I go to click on another element, it changes the padding of that element too. I have to click out of the Settings column on the right before clicking on a different element every single time, it's incredibly frustrating.

Im receiving a ton of spam or irrelevant traffic. Is there a way to block regions or countries? If not there needs to be one. I converted my website over from wp to GHL because of the automation ease. But the amount of spam i receive has me wanting to go back ASAP.

Currently, the builder mode (for some reason) is not allowing mobile dropdown menu configuration. It doesn't open when you click on it - and it used to. Don't know why the guys in the dev department decided to take that off, but from a UX perspective it creates a terrible experience, especially when using the mega menu - which it inherits the margins and padding from web version and as a result it disappears from the view in mobile. PLEASE FIX THIS ASAP - AS ITS NOT ONLY ANNOYING BUT ALSO WITHOUT LOGIC. Bring back the option to be able to open the dropdown menu for mobile in builder mode so it can be configured.

HighLevel currently injects every Google Font family and weight ever chosen in the account into every page, forcing browsers to download large, unused files and hurting Core Web Vitals. Please add a per-page font audit so only the families and weights actually referenced in the final CSS are loaded (or let us toggle fonts on/off per page). This will slash render-blocking requests and make green Lighthouse scores achievable without custom hacks.