Networks now have their own page, and member sites know they're members

Until earlier this month, FapStarsDB treated every porn site as a standalone catalog. A site existed, scenes belonged to it, performers worked on it. End of story. That worked while we were indexing solo studios, but it stopped working the moment we started ingesting offers that share casting, joining, and pricing across half a dozen domains. The catalog had networks in it; the site did not.

We’ve now built that out, partly. Network hubs render their own pages, and every member site that belongs to one wears a small badge above its catalog facts that says so and links back. A few other pieces are still missing on purpose, and one is missing because we just haven’t shipped it yet. This post is the map of what landed, what didn’t, and why.

What a network hub page is

When an offer has site_type='network_hub' in the database, it does not get a normal site page with its own scenes and performers. The hub doesn’t produce scenes. It markets, joins, and pays out for a cluster of sister sites that do. So we render it as an umbrella: headline numbers across the whole network, a grid of member sites, the top performers from anyone who’s shot for any of them, a recent-scenes rail, and an FAQ specific to the network.

Eleven hubs are live right now: Mom Lover, Brazzers, Teen Mega World, Nubiles Porn, Adult Time, plus six smaller ones. Mom Lover is the most populated example today, with eleven sister sites and 552 indexed scenes.

The body of the page is just stacked aggregation. The member-sites grid is the most useful block, because that’s the question someone landing on a network is actually asking: what’s inside this thing, and how recent is each piece? Cards show scene count, performer count, last release date.

The member-site bridge

The hub is one half. The other half is on every member site. If you land on a child site, say Smashed XXX or Cheating Mommy, we now render a sky-tone bar above the catalog facts panel saying which network it belongs to, how many sister sites share that membership, and how much total content sits behind it. Click and you’re on the hub.

Two design notes. First, the colour was contested internally. The hero panel on most FSDB site pages uses rose for the active CTA, and the first draft of this block reused rose. It read like a warning. Sky is the membership cue across the rest of the site (favourites, save state) and it carries the right meaning here, that the visitor is being offered a wider container of the same thing. Second, the block only renders when s.network_info is populated, so standalone studios get nothing instead of an empty card.

Why we’re not building per-performer network pages

The obvious next URL would be /pornstar/{slug}/on/{network}/, a page that crosses one performer with one network. We wrote the template, set the build flag to false, and left it. ENABLE_TIER2_PAGES=False in build.py and it’ll stay that way unless something changes in search behaviour. Two reasons. No-one is searching for "Whitney Wright on Brazzers" as a phrase, the query just doesn’t exist in the volumes that justify a separate page. And the page that is useful, the tier-1 hub at /pornstar/{slug}/, gets cannibalised when there’s a tier-2 sibling indexed underneath it. We tried this on a few performers earlier in the year, watched the hub lose impressions, and pulled them.

What’s still missing

Three things. The first one bothers me the most.

The performer page itself doesn’t mention networks anywhere. The filmography is still grouped strictly by site, so a performer who’s shot for four Mom Lover sister sites looks like she’s on four unrelated studios. The build pipeline actually computes the network membership of every site she appears on and passes it into the template context, but the template never reads that variable. The fix is small, the design isn’t. Do we group studios under network headers? Add a separate "appears across these networks" rail? Both feel right, both add weight to a page that already has a lot going on.

The second gap is on the home page and the sites index. Neither surface networks. A visitor can reach a hub only by clicking up from a member site or by typing the URL directly. We should probably have a small "networks we index" rail somewhere, but where it goes without making the homepage longer is an open question.

The third is internal hygiene. There’s no validator that catches a member site whose declared network_slug points to a hub with zero scenes (or no hub row at all). The "Part of network" block silently doesn’t render and we don’t notice until somebody loads the page. Cheap to add. Will add.

If you want to see the change in context, the easiest tour is to open any of the eleven hubs above and follow a member-site link. The pattern repeats. For the work this builds on, see the earlier note on folding filmography, since the network bridge sits in the same neighbourhood of the page.