Transcript
Intro
We asked Google's autocomplete about thirty films. One word turned up for every single one of them: cast. Not trailer, not reviews, but cast. Where to watch came second, for twenty five of the thirty. That little experiment is the start of a content plan built on what people actually type, instead of what a content calendar hopes they type.
In this episode we turn that into an attribute plan: a table that says what every page of one type must answer, ranked by real demand, plus what you skip on purpose.
Our guinea pig is ReelRadar, a fictional site about film trailers and where to watch films. Swap films for products, treatments or legal services, and every step still works.
Entity, attribute, value
Three words carry this whole episode. An entity is the thing, like a film. An attribute is a property every film can have, like its director. A value is the answer for one particular film. Entities in rows, attributes in columns, values in the cells, and congratulations, you now own a spreadsheet.
That grid is your content plan, whether you call it one or not, because searchers already think in it. Look at what follows a film's name in the search box: cast, release date, where to watch, box office. It's the same question asked about a different film, so solve the answer pattern once and it works for every film you list.
Google has a patent on this exact idea. Filed in 2012 and granted in 2015, it's called identifying and ranking attributes of entities. It splits logged searches into an entity part and a suffix, then counts how often each suffix shows up for one entity and across every entity of that type. A patent shows what Google invented, not what runs today, but it's the same move we're about to make with public data.
There's a newer reason to plan this way. Google says its AI features may fan one question out into several related searches. Is it worth watching Dune Part Two at home quietly contains the runtime, the streaming service and the reviews. An attribute plan is, in practice, the list of sub-questions those systems go hunting for.
Shared, rare, unique
Before the data, one more tool. We sort attributes into three groups. This is our working model for organising the work, not a Google system. Shared attributes apply to almost every entity of a type, rare ones apply to some, and unique ones apply to exactly one.
For films, cast and release date are shared, because every film has them. A soundtrack matters a lot for a musical and not at all for a courtroom drama, so it's rare. And some questions exist for one film only, like which emotions are new in Inside Out 2. That one is unique, and no template on earth will ever ask it.
Each group becomes a different build decision. Shared attributes become the template every page of that type carries. Rare ones become optional sections that switch on when there's something to say. Unique ones get written by hand, and they're often where a page says something no competitor does.
The same sort works far from film. Make a dental treatment the entity: cost, recovery time, how long the result lasts and who's a good candidate are shared. A guarantee or an anaesthesia option might be rare. A question only one treatment ever gets is unique. Different industry, same grid.
Thirty films of data
Now the data. Thirty real films: twenty two from 2024 and 2025, plus older ones like Titanic and The Shawshank Redemption. For each one we pulled the top ten autocomplete suggestions with US settings on the nineteenth of October 2026. That's three hundred suggestions from one afternoon and zero paid tools.
Then we sorted every suggestion into an attribute with plain, written rules. Anything with cast went to cast. Where to watch, streaming or a named service like Netflix went to where to watch. Review, Rotten Tomatoes or IMDb went to reviews and scores. Two hundred and thirty three of the three hundred landed somewhere, and each film counts once per attribute.
One warning before the chart. Autocomplete is not search volume. Google says its predictions reflect real searches, but they're shaped by language, location and trends, and they don't simply show the most common queries. Read this as a map of what people ask about, not a count of how many ask.
Here's the result, and cast covers all thirty films. Where to watch or streaming: twenty five, and release date: twenty two. Box office eighteen, reviews and scores seventeen, the trailer fourteen. Down at the bottom, runtime and director at eight each, and a parents guide at four.
Here's the full heat map, with attributes down the side and films across the top. Read it in rows. The cast row is solid, and where to watch is nearly solid. Lower rows break into scattered cells, and that scatter is your rare tier, drawn by data instead of by whoever talks loudest in the planning meeting.
Columns tell stories too. Most films matched between five and eight attributes. The Dark Knight matched only three, because six of its ten suggestions were about other entities: The Dark Knight Rises, the trilogy, and The Dark Knight Returns. That's the namesake problem from our entities episode, showing up live in the search box.
Now pull one pattern out of the heat map. Release date shows up for nineteen of the twenty two films from 2024 and 2025, and for only one of the five films released before 2015. Where to watch shows up for all five of the old ones. People stop asking when a film comes out once it's out. They never stop asking where to watch it.
That's a planning fact, not trivia. A release date section earns its keep for a few months and then quietly retires. A where to watch section stays useful for years, but its value keeps changing as films move between services. One attribute expires, the other needs maintenance, and your plan should say which is which.
Then the unique tier. Only Inside Out 2 drew emotions, anxiety and ennui. Only the new Fantastic Four drew Galactus and the Silver Surfer. Only The Shawshank Redemption drew book and Stephen King. And two 2024 films, Dune Part Two and Deadpool and Wolverine, drew popcorn bucket, so cinema marketing had quite a year.
Nobody puts those in a template, and they're real questions from real people. Shared attributes get you to the starting line. The unique ones are how you overtake.
On the page, a unique attribute is usually one short section under the shared template. ReelRadar's Inside Out 2 page keeps the same trailer, where to watch and cast blocks as every other film, then adds one section on which emotions are new. It's one paragraph to write, and it answers a question the template pages around it never touch.
You can run this for your own niche in an afternoon. Pick thirty entities of one type, pull suggestions for each, and sort them with rules written down so anyone can repeat them. Then count how many entities each attribute appears for, not how many times it appears. The script we used is free on the episode page.
Popular vs right for you
Now the step most plans skip. The most common attribute in our data is cast. So should ReelRadar build its pages around cast? No, because ReelRadar is a trailer and where to watch site, and its readers arrive wanting to watch something. Cast is popular, but here it's a supporting section, not the reason the page exists.
So we score every attribute twice. Demand: how often searchers attach it, straight from the data. Fit: how close it is to what the site is for and how it earns. Where to watch and trailer land top right, high demand and core purpose. Cast is high demand with medium fit, and box office is popular but nowhere near our purpose.
Google asks site owners a version of this in its own guidance: does your site have a primary purpose or focus? The same page warns against producing lots of content on many different topics in the hope some of it performs. Chasing every popular attribute is how a trailer site ends up writing box office analysis it has no edge in.
So here's ReelRadar's plan. Where to watch and the trailer lead every film page, and where demand is strong they get their own URLs. Release date and cast become fixed sections. Runtime, director and review scores become lines in a facts box. Box office, budget and popcorn buckets get nothing, on purpose.
A different site gets a different plan from exactly the same data. A film business newsletter puts box office and budget on top and ignores streaming. A family film guide promotes the parents guide row, which only four of our thirty films showed. Same table, different business, different priorities.
Values deserve a look too, because each attribute expects a type of answer. Release date wants a date, ideally per country. Runtime wants a duration. Where to watch wants a list of services that keeps changing. Answer a date question with a paragraph about anticipation, and you've got the attribute but missed the value.
And store every value with the date you checked it. Where to watch differs by country and changes when a film moves between services, so a value with no check date is a guess with good formatting. On a site like ReelRadar, the check date belongs on the page as well, right next to the answer.
Your schema is the same table
Here's the satisfying part. Your structured data is the same table, written in code. The schema dot org Movie type has properties for director, actor, duration and trailer, and it inherits the publication date, ratings and reviews. Every column in your attribute table maps to a property, so you've already done the hard bit.
Google's own Movie markup, which powers a movie carousel on mobile, requires only a name and an image. It recommends a director, a date, a rating and reviews, and every one of those is a shared attribute from our table. Google also says not to mark up anything users can't see, so each value goes on the page before it goes into the code.
So build in this order: table first, page second, markup last. If an attribute isn't in your table, it doesn't go in your markup. If it's in your markup, a reader should be able to find it on the page without opening the source code.
Four mistakes we see often in plans like this. One template for every entity, so the unique questions never get answered. Markup for values that aren't on the page. Attributes picked because a tool listed them, not because the site can answer them best. And changing values with no check date.
Two claims on trial
Claim one. Attributes are just keywords with a new name, so this whole episode was a rebrand.
A keyword is one string, like Oppenheimer cast. An attribute is the cast question asked of every film you'll ever cover, with a value type, a place in your template and a property in your markup. Google's own patent counts suffixes across every entity of a type, which a keyword list simply can't do. Placebo.
Claim two. Cover every attribute on one page, so the page is complete and nobody ever needs to leave.
This one depends. Shared attributes with short answers belong on the main page, because nobody wants a separate page for a runtime. But an attribute with big demand and its own intent, like where to watch a popular film, often earns its own URL, and a page that tries to answer everything serves no intent well. Decide per attribute, with data. Contested.
Our rule of thumb for an own URL has three tests. The attribute has demand of its own. It has a different intent from the main page. And its value changes often enough to need its own upkeep. Where to watch for a big film passes all three, and runtime passes none.
Wrap up
Here's the episode on one screen. Entities in rows, attributes in columns, values in the cells. Shared, rare and unique as a working model. Demand from data, fit from your business. And markup that mirrors the table you already built.
The attribute plan spreadsheet and the suggestion script are free on the episode page at irongoo.com. Next time, we zoom out from one page type to the whole site, and decide what a topical map should refuse.
