chrishutchins.com
Solid foundation,
leaking value

Seven categories, weighted. Nothing here is on fire. Two categories are doing the dragging.

Ranked by what they return for what they cost. Four of them are under 30 minutes. Six of the ten you can do yourself today.

1. Fix the About link

   Your nav and footer "About" link, on all 491 pages, points at /custom-about/. That page loads, shows almost nothing, then fires a JavaScript redirect to allthehacks.com/about/, which 301s back to www.chrishutchins.com/about/. Point the link at /about/ and 301 /custom-about/ into it. Same pattern on /custom-contact/. Every page's most important link about you is taking a detour through another domain.

   CriticalChris15 min

2. Fix the category page titles

   All three /categories/* pages print "| All the Hacks with Chris Hutchins" twice in the title tag, so they run 92 to 103 characters and get cut off in search results. These are three of your best hub pages and they look broken in the SERP.

   CriticalChris or Podpage10 min

3. Turn on transcripts

   Every episode page already ships an empty Transcript tab, and your own llms.txt documents a transcript.txt endpoint that currently 404s. The feature is installed and switched off. Start with the top 20 to 30 evergreen episodes and clean up the proper nouns before publishing. Full reasoning is in the content section below.

   HighChrisConfig, then editing

4. Retrofit Key Takeaways and FAQ blocks to the back catalog

   Both 2026 episodes we sampled have them. None of the four 2021 to 2024 episodes do. That puts roughly 290 of about 315 episodes on the old format. The winning format already exists on your site. It just never went backwards.

   HighChris or a VAEditing pass

5. Write real meta descriptions

   Six pages still carry Podpage's placeholder text, like "Contact page for All the Hacks with Chris Hutchins". Those are /about/, /products/, /contact/, /newsletter/, /sponsors/ and /categories/. Dashboard, Settings, SEO Metadata. This is free click-through rate.

   HighChris30 min

6. Send Podpage three support tickets about speed

   One: your HTML is not cached at the edge, cf-cache-status reads DYNAMIC on every page and server response time went from 908ms to 1,380ms in 25 weeks. Two: subscribe-button icons are served at 960px wide for a 24px display, about 427KB wasted per homepage load. Three: the YouTube embed on episode pages loads roughly 1MB before anyone presses play. We wrote the ticket text for you below.

   HighPodpage support3 tickets

7. Fix your own JavaScript error

   chrishutchins.github.io/podpagejs.js throws "Cannot read properties of null (reading 'addEventListener')" on your Home, Episode and Products pages. It is your file in your own GitHub repo. Add a null check before the listener. This is the one speed-adjacent item that needs nobody's permission.

   MediumChris5 min

8. Decide what the Products page is

   /products/ is set to noindex and nofollow, and the Podpage content block on it is empty. The screenshot is below. It is also listed in your sitemap despite the noindex, which is a small contradiction. Either fill it in or take it out of the nav and the sitemap.

   MediumChris20 min

9. Stop the nav leaking to the other domain, and collapse the redirect chains

   Your "Credit Cards" nav item goes to allthehacks.com/cardsnav and takes 5 hops to land. /deals/ goes through bit.ly and takes 4. Every allthehacks.com path takes 2. Point links at final URLs, and make allthehacks.com redirect in one hop. Your SiteNavigationElement schema currently tells Google your nav points off-domain.

   MediumChris30 min

10. Build three ranking assets out of content you already have

    You rank in the top 10 for zero of the six non-branded money queries we tested. Those results want guides and tables, not show notes. Turn /world-of-hyatt-deep-dive/ (2,781 words, zero tables) into a status-tier table page with the episode underneath. Build a /credit-card-transfer-partners/ matrix hub. Publish a dated "what are points worth" valuation table and refresh it quarterly.

    MediumChris or a writerContent project

Your robots.txt sorts crawlers into three groups. The first two are good news. The third one is worth a decision.

The left column is the one that matters most and it is exactly right. Every search engine and every AI search crawler is welcome with no throttling. Most sites we look at have accidentally blocked at least one of these. You have not.

What blocking those costs you, in practice: your own team cannot pull backlink or rank data for your domain through Ahrefs or Semrush, and neither can a sponsor doing due diligence before a deal. They see a hollow profile. Blocking Amazonbot also cuts Alexa and Amazon shopping signals. If none of that matters to you, leaving it is a fine, free choice. If it does, one line of robots.txt changes it. Our read: this is almost certainly a stock Podpage template and nobody ever chose it.

One flat sitemap, 491 URLs, every one with a lastmod date, no priority or changefreq clutter. That is how it should look. We pulled 25 URLs at random and every one returned a clean 200 with no redirect and a self-referencing canonical.

The canonical tag echoes your tracking parameters

This is the highest-risk technical finding and it is not visible from the dashboard. When someone opens chrishutchins.com/?utm_source=newsletter&utm_medium=email, the page's canonical tag points at that exact URL, UTM tags and all, instead of collapsing to the clean address. We confirmed the same behaviour on an episode page with ?utm_source=x. You share tracked links constantly, from the newsletter, from social, from show notes. Every distinct combination can become its own canonical identity. Ask Podpage whether canonical generation can strip utm_*, fbclid and gclid server side. It is not fixable from your admin panel.

This is the one we would fix before anything else. It is on every page of the site, it involves your most important entity page, and it takes about fifteen minutes.

Both /custom-about/ and /about/ return 200 directly, both are self-canonical, both are in your sitemap, and neither is noindexed. So you have two live About pages, and the one every internal link points at is the emptier of the two (1,507 characters of visible text versus 2,137). The fix is two steps: repoint the nav and footer link at /about/, then 301 /custom-about/ into it, or just delete the custom page. Then do the same thing for /custom-contact/ and /contact/.

Two more chains worth collapsing

Every hop costs a little crawl budget and a little link equity. None of these are fatal on their own. All of them are one link edit away from being zero.

Google is not going to punish you for this today. Your field LCP is 1,995ms and your INP is 53ms, both rated Good. What the lab data shows is different: the page appears quickly and then freezes for a while before it will respond to a tap. That is the feeling, and here is where it comes from.

Lab scores, four page types

Mobile Lighthouse runs use a throttled CPU, so treat the absolute blocking-time numbers as pessimistic. The ranking between pages is real.

Total blocking time, where the freeze lives

• Blog, mobile10,774ms
• Episode, mobile1,228ms
• Products, mobile1,040ms
• Home, mobile238ms

On the blog template, four scripts fight for the main thread at load: Podpage's own bundle costs 4,840ms of scripting, Google Tag Manager 1,601ms, the Facebook signals config script 1,461ms and fbevents.js another 1,293ms. Deferring Facebook Pixel and GTM until after first paint is the single biggest win available on this page.

Server response time is getting worse

The cause is visible in the headers: cf-cache-status: DYNAMIC on every page we tested. Cloudflare sits in front of your site but is not caching the HTML, so every visitor anywhere in the world waits for a fresh response from the origin. The blog template is worst, at 2,015ms with only 14.1% of visits rated Good. Blog and Products pages also send Vary: Cookie because of a CSRF cookie, which would defeat caching even if the cache headers allowed it.

Layout shift: desktop is the problem, not mobile

That gap is unusual and it means the shift comes from something a single lab run does not reliably reproduce. The likely suspects are the podcast player widget resizing after its JavaScript initialises, or DOM injected by Facebook and GTM. Worth opening the DevTools Performance panel on a desktop episode page once, naming the element, and sending that to Podpage rather than describing the symptom.

The 960 pixel icon bug

Your subscribe buttons for Apple Podcasts, Spotify, Overcast, Pocket Casts, Amazon Music, YouTube Music, Castbox and RSS are displayed at 20 to 34 pixels. Podpage's image resizer is being asked for a 960 pixel wide render of each one. The Overcast icon alone is 57,444 bytes. Lighthouse measured the Apple Podcasts icon at 125,372 bytes total with 125,330 bytes wasted, which is 99.97%. Ten icons account for roughly 427KB of the homepage's 1,089KB of image weight.

Third-party weight on the homepage

• static.podpage.com, the Podpage bundle1,425 KB
• YouTube, on episode pages only1,009 KB
• Google Tag Manager251 KB
• Facebook Pixel204 KB
• SparkLoop69 KB
• ConvertKit42 KB

Podpage's own bundle is the biggest number but it is Brotli compressed and cached for a year, so it is efficiently delivered. The YouTube embed is the one that hurts, because it loads about 1MB and takes 637ms to 1,230ms of main-thread time on an episode page before anyone presses play.

The one you can fix today

On Home, Episode and Products, the console throws Uncaught TypeError: Cannot read properties of null (reading 'addEventListener'). The source is https://chrishutchins.github.io/podpagejs.js, which is your own file on your own GitHub Pages repo. The script is attaching a listener to an element that does not exist on those templates. It does not fire on the blog template, which is the clue to which element is missing. Add a null check and redeploy.

Hi Podpage team, three performance items on chrishutchins.com:

1) HTML is not being cached at the Cloudflare edge. Every page returns
   cf-cache-status: DYNAMIC and cache-control: public, max-age=0,
   must-revalidate. Blog and Products also send Vary: Cookie from the
   csrftoken cookie. Our origin p75 TTFB has gone from 908ms to 1,380ms
   over 25 weeks (CrUX), and the blog template is at 2,015ms with only
   14% of visits rated Good. Can anonymous visitors be served a
   cacheable, cookie-free HTML response? Fixing this would likely also
   re-enable Brotli on the HTML, which currently falls back to gzip.

2) Subscribe-button icons are requested from img.podpage.com with an
   rs:fit:960:0:1 transform but render at 20 to 34 CSS pixels. Examples
   on our homepage weigh 57,444 / 55,900 / 53,600 / 45,040 / 40,804 /
   40,016 / 38,170 / 26,320 / 25,642 bytes. Lighthouse reports 99.97%
   wasted bytes on the Apple Podcasts icon. Can the transform width be
   matched to the rendered size for subscribe icons?

3) The episode template embeds a youtube-nocookie.com iframe above the
   fold with a lazyload class that does not actually defer it. It costs
   ~1,009KB of transfer and 637ms to 1,230ms of main-thread time before
   anyone presses play. Could the episode template use a click-to-play
   facade (static thumbnail, iframe injected on click)?

Also, if there is any way to defer Facebook Pixel and Google Tag Manager
until after first paint, our blog template shows 10,774ms of mobile
total blocking time, with 4,840ms from _combined-public.min.js,
1,601ms from gtag/js, and 1,461ms plus 1,293ms from Facebook.

And a lower-priority one: three vendor stylesheets (bootstrap-public,
boomerang-public, public_styles) are render-blocking and cost 900 to
1,200ms on mobile. Podpage already defers FontAwesome and Swiper CSS on
the same page, so the pattern exists.

Thanks!

We checked this by hand because it looked like a broken script. It is not. The page returns HTTP 200 and renders normally, and the same JavaScript error from the speed section fires here as it does on Home. The actual cause is simpler: the Podpage content container, <div class="user-added-content">, has no children in the raw HTML. Nothing was ever published into that block. We found the identical empty-container signature on /custom-about/, which confirms it is a generic unfilled Podpage block rather than a Products-specific bug.

Two loose ends around it. The page carries noindex, nofollow, which is the right call while it is empty, but the nofollow also stops link equity flowing through the nav links on that page. And the URL is listed in your sitemap despite the noindex, which is a small contradiction Google notices. Either populate the block and drop the noindex, or pull it from the nav and the sitemap until it is ready.

Your show notes are thin, and the fix is already built

We measured the unique body text on six episode pages spanning 2021 to 2026. Not the whole page, which runs 3,000 to 3,900 words once nav and footer are counted, but the actual show-notes block.

Word count is a coverage floor, not a ranking factor. A 700-word page that fully answers a question is fine. The real risk here is the ratio: 450 to 900 words of unique prose sitting inside a template that ships 39 to 40 images and 70 to 110 nav and footer links. At scale that is the shape quality raters are trained to notice, even though every individual page is legitimate.

Transcripts: yes, publish them

What we found on your site today. Your Podpage template already has the transcript feature built in. Every episode page ships an empty <div id="transcript"> tab in the HTML, and your own llms.txt file documents a <episode-url>transcript.txt endpoint, described there as "Episode transcripts, when available locally, are served as text/plain". We tested it on /world-of-hyatt-deep-dive/transcript.txt and got a 404. The capability exists and is switched off. That is a configuration gap, not a platform limit. Per Podpage's own documentation, transcripts import automatically from your feed's .srt or .json files if present, can be pasted manually per episode, or can be auto-generated with speaker labels and timestamps on the Elite plan.

What the other big podcasts actually do

What we would do on your site

1. Turn on the existing Podpage transcript feature for new episodes going forward. The tab and the endpoint already exist in your template, so the engineering cost is close to zero.
2. Use the collapsed tab your template already ships, not a separate /transcript/ URL. Tim Ferriss built his pattern before this in-page tab existed as a platform option. Keeping the transcript on the episode URL consolidates link equity and avoids a second thin page per episode.
3. Add speaker labels and clean up the proper nouns before publishing. Guest names, card names, program names.
4. Link your existing chapter timestamps into the transcript. You already publish good chapter markers on 4 of the 6 episodes we sampled. Anchoring them gives the transcript the same structure the show notes have.
5. Back-fill by priority. Start with the 20 to 30 most-trafficked evergreen episodes, the points and miles deep dives, the "What's in My Wallet" companions, the credit card strategy episodes. Not all 315 at once.
6. Do not duplicate onto allthehacks.com. If that domain surfaces the episode, link to the transcript rather than republishing it.

The Key Takeaways and FAQ retrofit

This is the cheapest win in the whole audit, because the format already exists on your site and it works. Compare two of your own pages:

Present on 2 of 2 sampled 2026 episodes. Absent on 4 of 4 sampled 2021 to 2024 episodes. Sample suggests roughly 290 of about 315 episodes predate the format. One editing pass per episode fixes both structure and freshness at the same time.

Freshness, and the 2024-07-26 problem

We cross-checked sitemap lastmod against the dateModified in each page's JSON-LD on all six episode samples and they agree, so lastmod here is a genuine last-edit signal rather than a template artefact. That is good news: republishing an updated evergreen post really does move the freshness signal. Nothing technical is blocking a refresh programme. There just is not one.

The "What's in My Wallet" year series

You have two URLs per year on this topic, an episode page and a blog companion, published the same day. They are not technically duplicate, because each has its own title and its own self-referencing canonical. They are a soft cannibalisation risk: same year, same topic, near-identical intent. The blog versions are longer and better structured (2,596 to 3,668 words with real H2 and H3 hierarchies) so they are probably absorbing most of the ranking value already. The bigger issue is that a searcher landing on the 2024 version in 2026 gets two-year-old card recommendations with no pointer to the current one. Add a "see the 2026 version" link from every older year.

Your structured data is unusually mature for a Podpage default install. One JSON-LD block per page, one @graph, and Organization, WebSite, PodcastSeries, PodcastEpisode, VideoObject, BlogPosting, BreadcrumbList and SiteNavigationElement all tied together with @id references. There are four specific gaps.

1. The category title bug, shown literally

This is what your <title> tag currently says on /categories/travel-points-miles/:

Travel, points + miles Episodes | All the Hacks with Chris Hutchins | All the Hacks with Chris Hutchins

103 characters, brand name twice. Same bug on /categories/money-investing/ (98 characters) and /categories/life-work/ (92). Google will cut this off around 60. These three pages are among the meatiest on the site, at 2,649 to 2,737 words each with about 40 unique internal links, and they present themselves in search like a template someone forgot to finish.

2. Six placeholder meta descriptions

Aim for 140 to 160 characters, written for a human deciding whether to click. Dashboard, Settings, SEO Metadata.

3. Your Person name is a greeting

Every page that references you carries "name": "Hi, I'm Chris Hutchins 👋" in the Person block. It is charming on the page and wrong in the markup. Set name to "Chris Hutchins" and move the greeting into description if you want to keep it. Related and more important: /about/ has no Person schema on it at all. Your Person entity lives at /people/chris-hutchins/, is referenced as the author on blog posts, and is never attached to the one page that is actually about you. That is the clearest missed opportunity on the site, and it connects directly to the "Chris Hutchins" search problem below.

4. PodcastEpisode is missing transcript and author

Confirmed absent on all three episode years we checked, 2026, 2024 and 2022, so the template has not changed on this front in four years. The episode object also uses timeRequired rather than the more standard duration. Both are valid, but duration is what podcast tooling and AI parsers expect, so add it alongside rather than replacing. One honest caveat: Google shut down Google Podcasts in 2024 and never had a PodcastEpisode rich result in classic search, so the value here is for aggregators, AI answer engines and Apple or Spotify adjacent tooling. Worth doing well. Not worth overselling.

{
  "@context": "https://schema.org",
  "@type": "PodcastEpisode",
  "@id": "https://www.chrishutchins.com/world-of-hyatt-deep-dive/#episode",
  "name": "Deep Dive on World of Hyatt: Points, Perks and Status",
  "url": "https://www.chrishutchins.com/world-of-hyatt-deep-dive/",
  "partOfSeries": { "@id": "https://www.chrishutchins.com/#podcastseries" },
  "episodeNumber": 294,
  "datePublished": "2026-09-09T09:00:00+00:00",
  "duration": "PT[HH]H[MM]M[SS]S",
  "timeRequired": "PT[HH]H[MM]M[SS]S",
  "associatedMedia": {
    "@type": "MediaObject",
    "contentUrl": "[megaphone mp3 enclosure URL]"
  },
  "author": {
    "@type": "Person",
    "@id": "https://www.chrishutchins.com/people/chris-hutchins/#person"
  },
  "transcript": {
    "@type": "CreativeWork",
    "url": "https://www.chrishutchins.com/world-of-hyatt-deep-dive/#transcript",
    "text": "[full transcript text once the Podpage field is populated]"
  },
  "image": { "@type": "ImageObject", "url": "[episode artwork URL]" }
}

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Deep Dive on World of Hyatt: Points, Perks and Status",
  "url": "https://www.chrishutchins.com/world-of-hyatt-deep-dive/",
  "author": {
    "@id": "https://www.chrishutchins.com/people/chris-hutchins/#person"
  },
  "publisher": { "@id": "https://www.chrishutchins.com/#organization" },
  "datePublished": "2026-09-09T09:00:00+00:00",
  "image": { "@type": "ImageObject", "url": "[episode artwork URL]" },
  "articleBody": "[show-notes text already on the page]"
}

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://www.chrishutchins.com/about/#person",
  "name": "Chris Hutchins",
  "url": "https://www.chrishutchins.com/about/",
  "jobTitle": "Founder / Host, All the Hacks",
  "description": "Avid optimizer and host of the All the Hacks podcast. Previously Head of New Product Strategy at Wealthfront, co-founder and CEO of Grove (acquired by Wealthfront), co-founder of Milk (acquired by Google), and an investor at Google Ventures.",
  "alumniOf": [
    { "@type": "Organization", "name": "Wealthfront" },
    { "@type": "Organization", "name": "Google Ventures" }
  ],
  "subjectOf": { "@type": "Movie", "name": "Playing with Fire" },
  "sameAs": [
    "https://twitter.com/hutchins",
    "https://www.instagram.com/chrishutchins",
    "https://youtube.com/@allthehacks",
    "https://threads.net/@chrishutchins",
    "https://linkedin.com/in/chrishutchins"
  ]
}

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://www.chrishutchins.com/#website",
  "url": "https://www.chrishutchins.com/",
  "name": "All the Hacks with Chris Hutchins",
  "publisher": { "@id": "https://www.chrishutchins.com/#organization" },
  "inLanguage": "en",
  "potentialAction": {
    "@type": "SearchAction",
    "target": "https://www.chrishutchins.com/search?q={search_term_string}",
    "query-input": "required name=search_term_string"
  }
}

You asked whether allthehacks.com and chrishutchins.com are competing. They are not duplicating content. Here is what is actually wired up today.

One detail to preserve in any scenario: your RSS feed at feeds.megaphone.fm/ATHLLC4474951365 is referenced from the homepage as a rel="alternate" link and is unaffected by either decision. Do not break it.

We ran eight live Google searches on 2026-09-16 and looked at what actually ranks. You rank for your brand. You do not rank for the money queries, and you do not rank for your own name.

None of those six non-branded results are owned by show-notes pages. They are owned by guides, tables and tools from The Points Guy, NerdWallet, AwardWallet, Upgraded Points and Prince of Travel. This is a page-type mismatch, not an authority problem. You have the knowledge. The page shape is wrong.

Three ranking assets you could build from content you already have

1. Turn /world-of-hyatt-deep-dive/ into a World of Hyatt status and points guide. The words are already there, 2,781 of them. What is missing is a benefits-by-tier table a reader can scan in ten seconds, put above the fold, with the episode and audio player underneath as supporting content, plus a visible "last updated" date. Same URL, same episode, different page shape.
2. Build a /credit-card-transfer-partners/ matrix hub. Today /credit-cards/ returns a 404 and the nav item by that name goes off-domain. You have almost certainly covered every one of these programmes across individual episodes. The missing asset is one evergreen page that aggregates them into a sortable table and links out to the relevant episode for the "why" on each one. No new research, just consolidation.
3. Publish a dated "what are points worth" valuation table. The Points Guy ranks for this because the page is mechanically refreshed and visibly dated. Publish an equivalent, refresh it quarterly, and cross-link it from every relevant episode. It is a recurring listener question, which means it is a recurring search.

The entity problem behind "Chris Hutchins"

Three things stack up here. Your homepage title is "All the Hacks: Upgrade Your Life, Money and Travel" and contains no mention of your name, on a domain that is your name. Your /about/ page has no Person schema. And there is no Wikipedia or Wikidata entity for you, which we confirmed by direct search, while a different Chris Hutchins does have one. Fixing the first two is free and is covered in the schema section. The third cannot be self-published, but the CNBC, New York Times, Wall Street Journal and Tim Ferriss mentions are the right building blocks for a future notability case. We did not independently verify those press mentions, so confirm them before anyone cites them as done.

We could not corroborate that number with the tools available in this audit, and we want to be straight about why. The Moz API key returned "Invalid Moz API key" on every call. Bing Webmaster Tools has no verified property for this domain. Ahrefs itself is blocked by your robots.txt. Nothing we found contradicts DR 45, but nothing here confirms it either. The DR 45 figure is Nick's own reading from his Ahrefs account.

What we could pull is the Common Crawl web graph, which gives relative ordering only.

Ten places worth a link, all confirmed to exist

1. Podpage's own spotlight post about All the Hacks. The platform you pay for already wrote about you. Confirm it links to chrishutchins.com with a followed link. Zero outreach cost.
2. The Tim Ferriss Show episode page for your guest appearance. tim.blog ranks far above you in the table above. Confirm the show notes link out and that the anchor text includes "All the Hacks".
3. ChooseFI episode page for your appearance. Confirmed live link. Easy to request an update if consolidation changes any URLs.
4. The Speaker Lab guest episode. Confirmed live link, anchor text "Listen to All the Hacks podcast".
5. Creator Science guest page. A guest bio page, good candidate for an unlinked-mention check.
6. Nathan Barry's podcast episode page from January 2026, on growing a podcast. Verify or request a link.
7. Zero to Travel's feature post, a full write-up of the best hacks from your show. Strong candidate for full attribution.
8. Podchaser creator profile. Claim and complete it, and make sure the "elsewhere" links point at chrishutchins.com.
9. Listen Notes podcast page. Already links to you. Verify it stays current after any domain cleanup.
10. BiggerPockets Money and BiggerPockets Real Estate. You are a repeat guest. Request show-notes links on any episode pages that do not have one yet.

Two more link-adjacent notes

Reddit and YouTube matter more than backlinks for AI citation. In the correlation data behind our GEO scoring, YouTube mentions sit around 0.737 and Reddit is high, while backlinks sit around 0.266. Two cheap moves: make sure every YouTube upload has a full, keyword-rich description that links back to the matching show-notes page, and consider an AMA or a genuine presence in r/churning and r/awardtravel tied to specific episodes.

Your Tim Ferriss appearance is a citable authority asset you are not using. Neither /about/ nor /people/chris-hutchins/ references it today.

The image work is better than the markup suggests. Podpage's proxy auto-converts everything to WebP at sensible quality, your social preview images are generated per page at exactly 1200 by 630 and weigh 34KB, and your favicon set is complete from 16px up to 256px plus a 180px Apple touch icon. Where alt text exists it is genuinely descriptive, not filename noise. Three things are worth fixing.

1. The cartoons have empty alt text. The pig and the earth illustrations sit inside your homepage body copy, so they are content, not decoration, and both ship with alt="". Describe them. It takes a minute and it is the kind of detail that makes the rest of the site's polish believable.
2. They are also over-served. The pig is 55.9KB displayed at 215 by 191 pixels. The earth is 43.9KB displayed at about 321 by 310. Both are requested from the proxy at 960 pixels wide. This is the same URL-parameter issue as the subscribe icons, not a file-optimisation job.
3. Most in-article images have no width or height. 29 of 40 images on one episode page, 28 of 39 on another, including the episode artwork itself. That is a layout-shift risk, and it lines up with the desktop CLS number of 0.34 in the speed section. Adding intrinsic dimensions or a CSS aspect-ratio to the episode template's image component is the cheapest fix in this section.

One more, purely cosmetic: your favicon link tags are typed image/x-icon but the files are actually WebP. Nothing breaks. Correct it if you are in there anyway.

The secondary findings, all Medium or Low. Nothing here should jump the queue ahead of the top ten, but each one is real and each one is cheap.

Audit date 2026-09-16. Everything in this document was measured from outside the site, with public data only.

Tools

• The claude-seo toolkit v2.3.1, which wraps Google PageSpeed Insights v5, the Chrome UX Report API with 25 weeks of history, the Common Crawl web graph, and Playwright for screenshots.
• curl with a Chrome browser user agent. Your site returns HTTP 403 to plain curl, so every fetch used a real browser identity.
• Live Google searches for eight queries, run on the audit date from US results.
• Podpage's own product and support documentation, for what is and is not configurable.

What we sampled

What we could not see

How the work was done

Five specialist agents ran in parallel, one each for technical and sitemap, performance, content and AI search, schema and on-page and images, and backlinks and domain strategy and search experience. A lead agent cross-checked their findings against each other, and disagreements were resolved by re-fetching. Two examples: the About page JavaScript redirect was first reported as a plain 301 and had to be verified by hand, and the blank Products page was first reported as a rendering failure before a screenshot and a raw-HTML check showed it is an empty content block. Nick reviewed the result and wrote the yellow notes himself.