Omegro Podcast — Fix List

01The schema

Done and verified 28 August. All five blocks parse cleanly on both pages.

The validator reported one uncategorised error. There are actually three separate problems, and only two of them are in the podcast build. Fixing them in this order is easiest.

Fix the trailing comma in the site wide Organization block

Go to Site settings, Custom code, Head. Find the Organization block and look at the sameAs list. There is a comma after the Crunchbase URL with nothing following it. That single character makes the whole block invalid, on every page of the site, not just the podcast. Easiest fix is to replace the whole block with the corrected version below.

Corrected Organization block, paste over the existing one
```
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Omegro",
  "url": "https://www.omegro.com",
  "logo": "https://cdn.prod.website-files.com/69a18ad446d139c570df107d/69a456cf0e454c0d55030589_Omegro-Mineral-Med-BG-Logo-768x432.png.webp",
  "description": "Omegro is a people-first, buy-and-grow acquirer of enterprise asset management and fleet software companies, offering a permanent and safe home for long-term, sustainable growth.",
  "sameAs": [
    "https://www.linkedin.com/company/omegro",
    "https://www.crunchbase.com/organization/omegro"
  ]
}
</script>
```
Note. This one sits in the site wide custom code, so it already has its own <script> tags around it. Keep them. This is the only block on this page that needs them.
Done
Split the episode schema into two blocks

Open Podcast Episodes Template, page settings, Schema markup. The PodcastEpisode and the FAQ are currently sitting in one field together. A block can only hold one JSON object, so the FAQ is being read as junk stuck on the end of the first one. Use the option to add a second JSON‑LD block, so you end up with one block for each.
Done
Replace the PodcastEpisode block

Two things are wrong in the current one. The url and the partOfSeries url both still say /en/podcast/, which does not exist on the site, so the schema is pointing at a 404. And the name value has a stray space at the front.

Paste this into the first block, then put your CMS field bindings back on the five values marked in square brackets.

Block 1 of 2 — PodcastEpisode
```
{
  "@context": "https://schema.org",
  "@type": "PodcastEpisode",
  "url": "https://omegro.com/podcast/[Slug]",
  "name": "[Name]",
  "datePublished": "[Publish Date]",
  "description": "[Summary]",
  "timeRequired": "[Audio Duration]",
  "associatedMedia": {
    "@type": "AudioObject",
    "contentUrl": "[Audio URL]",
    "encodingFormat": "audio/mpeg"
  },
  "partOfSeries": {
    "@type": "PodcastSeries",
    "name": "The Omegro Effect: EAM Unlocked",
    "url": "https://omegro.com/podcast"
  }
}
```
Watch the space. When you re‑bind the [Name] field, make sure there is no space between the opening quote mark and the field token. That leading space is what is showing up in the live markup now.
Done

Replace the FAQ block

The current one repeats the closing bracket and brace after every question, so only the first question is inside a valid FAQPage and the other four are floating loose. All five need to sit inside one mainEntity array. This version is complete and needs no bindings, so it can go straight in.

Block 2 of 2 — FAQPage

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What drives the best acquisition outcomes?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "The best acquisition outcomes happen when the buyer's operating model aligns with what the seller wants for their business, people and legacy."
      }
    },
    {
      "@type": "Question",
      "name": "Is choosing the highest valuation always the best option?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Choosing the right buyer is about more than valuation. It is about finding a long term partner that can help the business continue to grow after close."
      }
    },
    {
      "@type": "Question",
      "name": "Why does deep industry expertise matter in an acquisition?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Buyers who understand your customers, market and challenges can often provide more value than capital alone."
      }
    },
    {
      "@type": "Question",
      "name": "How are the strongest acquisition relationships built?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "The strongest acquisition relationships are usually developed over years of conversations rather than during a single transaction process."
      }
    },
    {
      "@type": "Question",
      "name": "What are the benefits of long term ownership?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Long term ownership enables businesses to preserve their legacy while benefiting from shared expertise, leadership development and continuous improvement."
      }
    }
  ]
}

Done

Publish, then validate the live URL

Run the live episode page through validator.schema.org using the URL box this time, now that the page is public. You should see PodcastEpisode, FAQPage and Organization all come back clean.

The URL to test
```
https://omegro.com/podcast/the-right-owner-changes-everything-from-acquisition-to-growth
```
Done

02The accordion

Done 28 August. Confirmed working on the live episode page.

Move the accordion script so it loads everywhere

The script that opens and closes the accordion lives in the Acquisition Process page's own custom code, in the before body tag field. It is not in the site wide code, so it never loads on the episode template and nothing can collapse.

Copy that script out of the Acquisition Process page settings and paste it into Site settings, Custom code, Before body tag. Then delete it from the Acquisition Process page, otherwise it loads twice on that page and the click handlers fight each other.
Done
Add the class the script is looking for

Even with the script loaded it still would not fire, because the class names do not match. The script looks for dd-ac__card with two underscores. Your podcast cards are dd-ac__card-2 and dd-ac_card-podcast, and that second one has a single underscore. Neither matches.

In the Designer, select the accordion card wrapper on the episode template and add this class alongside the ones already on it. Do not remove the existing classes, they carry your styling.

Class to add
```
dd-ac__card
```
Why this works. The script also needs dd-ac__card-content and dd-ac__card-icon inside each card. Both of those are already correct on your build, so this one class is the only thing missing.
Done
Publish and test

Open the episode page and click one of the three headings. It should expand smoothly and the arrow should rotate. Opening one should close the others.
Done

03Three quick ones on the episode page

Two of three done. Only the empty Related Resources band is left.

Make the episode title an H1

The title is currently set as an H3, and the page has no H1 anywhere on it. The first H2 sits right down in the related resources band, so the heading order runs backwards. Change the episode title element to H1. It is the strongest single signal both search and AI use to work out what a page is about, and at the moment the page does not have one.
Done
Point the hero video at the episode, not the playlist

The Video Embed field still carries the playlist and timestamp parameters, so the embed resolves to a YouTube videoseries player. Someone landing on the page can end up watching the trailer instead of Episode 1. Delete everything from &list= onwards so only the video URL is left.
Done
Deal with the empty Related Resources band

Related Resources on Episode 1 is empty, so that section renders as a blank strip at the bottom of the page. Either add two or three genuinely relevant links, or set the section to hide when the field is empty using conditional visibility. A forced link is worse than none, so if nothing fits yet, hide it.
Done

04The consent banner

About 20 minutes. Rewritten 28 August, my earlier advice here was wrong.

Correction. I told you Webflow had a built in banner that would do the job. Webflow does have one, under Project settings and then Privacy, but it only shows a notice. It does not stop scripts running before someone accepts and it does not keep any record of consent. For GDPR those two things are the entire point, so the built in banner is decoration. You were right to go looking for an app.

There is still no consent banner live, and GA4, the LinkedIn Insight Tag and Lead Forensics are all firing the moment a page loads.

Consent Pro is the right pick. It is built by Finsweet, which the site already runs, so it fits the stack. It auto detects scripts and blocks them until someone consents, it stores the consent records for you, and it supports Google Consent Mode. That is exactly the gap the Webflow banner leaves.

Check the cost with Lynne first

Consent Pro is not free, so this one is not purely your call. It is free to test on staging, then paid to go live. At the time of writing it is around 199 US dollars as a one off lifetime licence, or a subscription if you prefer. One licence covers one site. Worth a quick word with Lynne before you install so the cost is not a surprise.
Done
Install it and set it to opt in

Set the banner so nothing in the marketing category fires until someone actively accepts. Implied consent, where scripts run while the banner sits there, is the thing that fails an audit.
Done
Test it on staging before you publish

Load the staging site in a private window with the browser network tab open. Before you click accept you should see no requests to Google Analytics, no LinkedIn tag and no Lead Forensics. After you accept, all three should appear. If any of them fire before you accept, the banner is not actually blocking and it needs another pass.
Done
Publish and check once more on the live site

Same test on the real domain. Then it is done.
Done

05The episode is live at two URLs

About 10 minutes. This is the heading you could not trace.

You asked where the heading in the top banner was pulling from. It is not coming from the podcast build at all. Episode 1 exists twice on the site.

omegro.com/podcast/the-right-owner-... is the real episode page, with the transcript, the show notes and all the schema.
omegro.com/resources/the-right-owner-... is a second page, generated by the Resources CMS item you created so the episode would show up in the Resources filter.

The heading you are seeing is the Resources template hero pulling the Name field off that second item. That is why you could not find it on the podcast template. It was never there.

The bigger issue. Two live URLs for the same episode compete with each other. The Resources copy has its own canonical tag pointing at itself, its own title and its own H1, but almost none of the content and none of the podcast schema. So a search engine or an answer engine can pick the thin one and ignore the real page. That undoes a good part of the work in section 01.

Point the Resources card at the podcast page

On the Resources listing, set that item's card link to /podcast/the-right-owner-changes-everything-from-acquisition-to-growth rather than to its own Resources page. People filtering to Podcast then land on the real episode.
Done
Add a canonical field to the Resources collection

Add a plain text field called Canonical URL to the Resources collection. On the podcast item, set it to the full podcast URL below. Then in the Resources template page settings, bind the canonical URL to that field. Leave it empty on every other Resources item and they behave as they do now.

Canonical URL for that item
```
https://omegro.com/podcast/the-right-owner-changes-everything-from-acquisition-to-growth
```
That tells search engines the podcast page is the real one and the Resources copy is a pointer. The duplicate stops competing.
Done
Publish and check

Load the Resources copy and view the page source. The canonical tag should now point at the podcast URL, not at itself.
Done

Worth considering later. The cleaner fix is to have the Resources filter read the Podcast Episodes collection directly, so no duplicate item is needed at all. That is more work and it is not urgent, but it is the version I would aim for once there are a few episodes and you are creating a Resources twin for every one of them.

06Mobile

About 15 minutes for the lot. Far less work than it looks.

The short answer: no, you do not restyle every element at every size. Webflow styles cascade downward. Desktop is the base, and anything you set at a smaller breakpoint applies to that size and every size below it, and never touches desktop. So you go to one breakpoint and override only the handful of things that actually break.

Better still, make these changes at the Tablet breakpoint rather than at mobile. Tablet cascades down into both mobile landscape and mobile portrait, so one change covers all three smaller sizes instead of three separate ones.

I checked both pages at 375 pixels wide. Nothing overflows the screen, which is good, but several blocks are still sitting as two columns when they should stack. That is what makes the text column narrow and squashes the video and the guest cards. Every one of them is the same one property fix.

Set each of these to a single column at Tablet

Episode page
  .podcast-episode-wrapper     currently 226px / 96px   <- the hero, worst one
  .podcast-platforms-layout    flex row, should wrap
  .collection-list-6           the guest grid, 2 cards side by side
  .podcast-guest-card          image and text inside each card
  .podcast-signup-panel        206px / 89px

Hub page
  .why-listen-benefits         2 columns inside 189px
  .podcast-signup-panel        same class, fixing it once fixes both pages

Switch each grid to one column

Select the element, go to the Tablet breakpoint, and in the Grid settings set the columns to 1. For the flex ones, either set the direction to vertical or turn wrapping on. That is the whole change. The desktop layout is untouched.
Done
Fix the hub hero cover image

On the hub, the cover art card runs off the right edge on a phone. Give the image a max width of 100 percent at Tablet so it scales inside its column rather than keeping its desktop width.
Done
Check the heading size at mobile

Once the hero is one column the H1 gets the full width back, which fixes most of the awkward wrapping on its own. If it still feels large, drop the font size a step at Tablet rather than editing it at every breakpoint.
Done
Publish and look at it on your phone

Webflow's preview is close but not identical. Worth thirty seconds on a real handset.
Done

Leave these ones alone. The navigation bar, the footer blocks and the newsletter checkboxes also sit as tight rows on mobile, but they are the existing site rather than anything in the podcast build. They behave the same on every other page. Worth raising separately rather than changing them inside this job.

Rule of thumb from here on. If a block is two or more columns on desktop, it needs a single column override at Tablet. That is the only recurring mobile change on this kind of layout, so future episode pages will inherit it once these classes are fixed.

07Worth doing before Episode 2

About 20 minutes, and it saves you repeating step 4 every fortnight.

The takeaways live in a rich text field, which is why the FAQ block has to be hand built for every episode. Add five pairs of plain text fields to the Podcast Episodes collection, Question 1 to 5 and Answer 1 to 5, then bind the FAQ block to them once. From that point on the FAQ fills itself in from the CMS entry and you never touch the code again.

One habit worth keeping. Write the takeaway questions the way a founder would actually type them into a search box, and use exactly the same wording in the visible Q&A on the page and in the FAQ markup. Matching those two is what turns a takeaway into a citation.

Noted for Episode 2

08What is already right

No action needed, listed so nothing gets changed by mistake.

Lead Forensics is live. You were right, and I was wrong in my last email. It is loading under the 365-syndicate.com host, which is why searching for the name Lead Forensics in the page source turns up nothing. It is present on both the hub and the episode page.

Confirmed on the live site, 28 August. Schema now validates on both the hub and the episode page, with PodcastEpisode, FAQPage, PodcastSeries and Organization all parsing cleanly. The accordion opens and closes. The episode title is an H1. The hero video points at the single episode rather than the playlist. The ActiveCampaign podcast tags are in.

The transcript reads cleanly now, with speaker names and timestamps, and it sits in the page as real text rather than a file, which is exactly what makes it citable.
Topic tags are down to three, so the filter has something meaningful to filter on.
The invalid Webflow RSS feed is gone and the subscribe link points at the anchor.fm feed.
The episode is showing correctly in Resources under the new Podcast content type.
GA4 is live, and the hub schema validates cleanly.
The View episode details label is a better call than transcript. It describes where the click goes and it keeps people on the page Omegro owns. Leave it as it is.

09Waiting on other people

Not blocking the fixes above.

Annie, on UTMs for the links back from Spotify, Apple, YouTube and Instagram, so you can tell which platform actually sends people to the site.
Scott, on the heading appearing in the top banner. The screenshot did not come through on my copy of the email and both pages look correct to me in the markup. Send it again or tell me which URL and I will find it.

01The schema

Fix the trailing comma in the site wide Organization block

Split the episode schema into two blocks

Replace the PodcastEpisode block

Replace the FAQ block

Publish, then validate the live URL

02The accordion

Move the accordion script so it loads everywhere

Add the class the script is looking for

Publish and test

03Three quick ones on the episode page

Make the episode title an H1

Point the hero video at the episode, not the playlist

Deal with the empty Related Resources band

04The consent banner

Check the cost with Lynne first

Install it and set it to opt in

Test it on staging before you publish

Publish and check once more on the live site

05The episode is live at two URLs

Point the Resources card at the podcast page

Add a canonical field to the Resources collection

Publish and check

06Mobile

Switch each grid to one column

Fix the hub hero cover image

Check the heading size at mobile

Publish and look at it on your phone

07Worth doing before Episode 2

08What is already right

09Waiting on other people