Link main-site past-event/episode entries to the podcast page instead of YouTube (internal linking + crawlability)

Feedback (from content audit)

On the main DataTalks.Club site, the past-events list → individual event currently links straight to YouTube, instead of to the podcast page (transcript, recording, guest/author info, similar podcasts — the page built for people to actually interact with the site).

"Instead of using the podcast page on our site — where people can read the transcript, watch the recording, learn about the author and guests, see similar podcasts, interact with the site — it links to YouTube. I think it's tied to how [the RSS/automation] is configured right now, but if we can change it, probably more people would land on the podcast pages. People would also understand that this past event is connected to that podcast page. And crawler bots would see that link — otherwise these pages are just floating in the air, not linked from anywhere on the site. The more links point to a page, the more likely crawlers notice it."

Why it matters

1. Traffic — routes visitors from a high-traffic surface (past events) to the podcast pages instead of leaking them to YouTube.
2. Crawlability / SEO — podcast pages currently have few/no inbound internal links ("floating in the air"), so crawlers barely discover them. Inbound links are what make pages get indexed and rank. This is the crawl-orphan problem already noted in SEO_INTEGRATION.md §3c.
3. User comprehension — makes the event↔episode relationship explicit.

⚠️ Cross-repo + reconcile with the SEO plan

• This change likely lives in the main site repo (datatalksclub.github.io) and/or the RSS/automation config that generates event entries — not in podwiki itself.
• Reconcile with the current SEO decision (SEO_INTEGRATION.md, resolved 2026-07-02): podwiki's _podcast_summaries episode pages are now output: false and canonical to the main-site /podcast/x.html. So the link target should be the main-site /podcast/x.html page, not a podwiki URL. Decide whether/how the podwiki graph/explore experience gets surfaced from there.

Related

• Motivated by #12 (low podcast-page traffic).

Source: content-audit feedback (translated from Russian voice note).

Start with SEO_INTEGRATION.md §3c and inspect the main site's past-events entry generation alongside the RSS/automation configuration mentioned in the issue. Confirm how event entries resolve podcast targets, then verify that they link to the main-site /podcast/x.html pages and that the event-to-episode relationship is crawlable.