Automating page classification with AI
How I turned my information architecture into an AI-powered decision system that classifies B2B pages at scale.
Role
Lead UX Designer
Project Type
In-House | Morningstar
Year
2026
It’s me, hi, I’m the problem, it’s me
As part of redesigning Morningstar’s B2B information architecture, I created a governed system of page types to bring consistency to the B2B website.
There was just one problem: I was the only person who knew how to apply it.
That was manageable when a marketer requested a single new page. But with upcoming site migrations requiring hundreds of pages to be classified, I was about to become a serious bottleneck.
I needed to make my own IA expertise scalable and accessible.
Turning judgment into logic
My first idea was simple: let someone describe the page they wanted to create and have AI recommend the right page type.
But a page-type definition wasn't enough. I had to ask myself:
What information do I rely on to make this decision?
I started making my own judgment explicit.
I modeled our page types as entities and mapped their relationships. Then I created classification logic based on URL structure, HTML signals, titles and H1s, metadata, sitemap placement, content patterns, and anti-patterns—with confidence levels for each signal.
Refining the logic
Early versions of the Skill made incorrect recommendations. Pages that were really closer to product category pages were getting classified as Product Pages because of the way they were named. I needed better documentation.
I partnered with SEO and Development to understand how to bake in more logic to my documentation. They helped me identify schema and metadata signals the Skill could use alongside the page content.
As a result my documentation got tighter. And as my documentation got tighter, the Skill got better.
Break in case of emergency
Great, now we have logic. But what if nothing fits? I deliberately designed the Skill not to force an answer.
If there's a strong match, it recommends a page type. If multiple types are plausible, it surfaces alternatives. If information is missing, it asks for more context. And if nothing fits, it says so.
That last scenario comes back to UX: do we allow a rare one-off, or have we discovered a recurring need that warrants a new page type?
Show your work
I didn't design the Skill to simply return “Product Page.”
I don't trust AI output at face value.
It provides the recommendation alongside its confidence, rationale, supporting signals, and alternatives.
Now, a human can validate the reasoning without recreating the analysis from scratch.
The goal isn't to remove human judgment. It's to automate the repeatable decisions so UX can focus on the ones that actually require judgment.
From a day's work to about an hour
The Skill is still in active testing, but one current migration gives us an early indication of its potential.
A microsite we're migrating contains roughly 50 pages across products, webinars, newsletters, legal content, and thought leadership.
Manually reviewing and confidently classifying those pages took our junior UX designer about one working day (8 hours).
Even processing the URLs individually, we estimate the Skill could complete the same classification work in about an hour, with the human focused on validating recommendations instead of analyzing every page from scratch.
That’s an estimated 88% reduction in time to classify.
Unintended (positive) side effects
There's another benefit I didn't anticipate:
Building the Skill forced me to document decisions that had previously lived mostly in my head. That made the AI better but it also made the underlying information architecture stronger, easier to govern, and easier to defend when stakeholders question why the system works the way it does.
The documentation also laid the groundwork for the logic behind my Benchmark Analysis.
I started out trying to automate page classification. I ended up making the architecture itself more scalable.
Now, how do i do this at scale?
Today, a user can provide a URL and the Skill evaluates the page against the framework. For bulk migrations, the same logic can produce structured classifications across many URLs.
Next, I'm testing the Skill at site scale: giving it a sitemap.xml file and having it return a spreadsheet of recommendations for every URL.
That introduces a new edge case: what happens when a page shouldn't be migrated at all? I'm exploring how the Skill can flag URLs for consolidation or removal instead of forcing a page-type recommendation.