A couple of years ago I started FandomWatch, a site covering Netflix news and Stranger Things content. What began as a small hobby project turned into a real publication with regular traffic, and along the way I learned a lot about running a content-heavy WordPress site the right way. Here's a breakdown of the stack, the decisions, and the mistakes.
The Starting Point
I knew I wanted a fast, flexible site that didn't lock me into a rigid page builder or theme. Most entertainment/news sites end up bloated — too many plugins, too many trackers, pages that take five seconds to load. I wanted to avoid that from day one.
So the stack ended up being:
- WordPress as the CMS (still the fastest way to get a content site live and let non-technical writers publish without touching code)
- Bricks Builder for the front end (a visual builder that outputs clean HTML instead of the shortcode soup you get with a lot of page builders)
- Google Site Kit for tying together Analytics, Search Console, and AdSense from one dashboard
Structuring Content for a Niche Audience
The biggest early decision was how to organize categories. I didn't want a generic "blog" — I wanted something that felt like a real hub. So the taxonomy ended up being:
- News and Gossip
- Netflix
- Stranger Things (the flagship category, since that's where most of the traffic comes from)
- Streaming Guides
Keeping categories tight instead of sprawling made two things easier: internal linking (which matters a lot for SEO on a content site) and letting return visitors quickly find what they actually care about.
The "Netflix Library" Widget
One feature I'm genuinely proud of is a live-ish widget on the homepage that shows how many titles are currently on Netflix US, broken down by category, and what's new that week. This isn't something WordPress does out of the box — it needed:
- A custom data source that gets updated regularly (I don't want to name the exact method here since it's part of what makes the feature work, but the short version is: don't try to scrape Netflix directly, it's fragile and against their ToS — go through a proper structured data source instead)
- A lightweight custom post type/meta field setup so the numbers update without touching the widget's markup
- Caching, because without it this kind of dynamic block will tank your page speed score fast
If you're building something similar, my advice is: decouple the data update job from the page render. Update a cached value on a schedule (cron job or scheduled action), and just have the front end read that cached value. Don't hit an external source on every page load — that's the single biggest performance mistake I made in the first version.
Monetization Without Wrecking Page Speed
AdSense is the main revenue source, set up through Site Kit rather than manually inserting ad units. A few things that actually moved the needle on Core Web Vitals once ads were in the mix:
- Lazy-loading ad units below the fold
- Reserving ad slot dimensions ahead of time so ads don't cause layout shift (this alone fixed most of my CLS issues)
- Keeping ad density lower than what AdSense "recommends" — more ads per page usually means worse engagement and worse long-term RPM, not better
SEO for an Entertainment/Fandom Niche
This niche is brutally competitive and heavily SEO-driven, so a few practical lessons:
- Freshness matters more than in most niches. Fandom content (leaks, casting news, episode guides) has a short shelf life, so updating older posts when new information drops (like runtime reveals or season announcements) keeps them ranking instead of letting them die.
- Structured data is worth the setup time. Article schema, breadcrumbs, and FAQ blocks where relevant genuinely helped with rich snippets.
- Internal linking between related theory/news posts (e.g., linking a "what happened in the finale" post to the "who dies" post and back) kept session duration up, which indirectly helps rankings.
What I'd Do Differently
If I started over, I'd:
- Pick a theme/builder combo earlier and commit, instead of migrating mid-way through (I did migrate once and it cost me a few weeks of cleanup)
- Set up caching and image optimization before traffic ramped up, not after performance started slipping
- Build the "live stats" widget with a proper scheduled job from the start instead of retrofitting caching onto something that was originally doing live lookups
Closing Thoughts
Running a content site isn't just about writing — a huge chunk of the actual work is infrastructure: making sure pages load fast, data stays fresh without killing performance, and the CMS doesn't get in the way of publishing regularly. WordPress gets criticized a lot for being "bloated," but with the right builder and a disciplined plugin list, it's still one of the fastest ways to get a real publication off the ground.
Happy to answer questions in the comments if anyone's building something similar.
Tags: #wordpress #webdev #showdev #seo #buildinpublic
