ChatGPT answers, unedited

For a mid-size publisher with large content volumes, I’d prioritize SEO features that improve crawlability, discovery, topical relationships, and editorial efficiency rather than building lots of one-off SEO controls.

Priority order

Google explicitly emphasizes crawlability and discovery for large sites, and its documentation notes that duplicate URLs can reduce crawling efficiency because Google crawls canonical URLs more regularly than duplicates. Google for Developers Google for Developers

For internal-link recommendations, build this first

I'd make the recommendation engine editorial + algorithmic, rather than simply "articles containing similar keywords."

For every article, calculate candidate links using:

1. Semantic similarity

• Embeddings between the current article and candidate articles.
• Particularly useful when two articles use different vocabulary for the same topic.
• Entity overlap

• People, places, organizations, subjects, products, events, etc.
• Stronger signal than raw keyword overlap for publishers.
• Topic hierarchy

• Sports → NFL → Teams → Miami Dolphins
• Technology → AI → Generative AI → Models
• Let links reinforce the site's information architecture.
• Query/intent relationship

• Prefer links where the destination answers a natural next question.
• Example: an article about how mortgage rates work could recommend current mortgage rates and how the Fed affects mortgage rates.
• Destination value

• Give more weight to important evergreen pages, commercial landing pages, major hubs, and strategically important archive pages.
• Link saturation

• Don't recommend the same destination from hundreds of articles simply because it's semantically similar.
• Cap recommendations per source/destination/topic.
• Freshness

• For news publishers especially, recommendations should distinguish evergreen content from expired stories.

The UX I'd give editors

Inside the CMS, something like:

Recommended links

• "What is the Fed funds rate?" → Federal Funds Rate Explained
• "mortgage rates" → Current Mortgage Rates
• "interest-rate decision" → Federal Reserve Interest Rate Decisions

Why: strong topic match + entity overlap
Suggested anchor: Federal Reserve interest-rate decisions
Confidence: High

Then give the editor Accept / Edit anchor / Dismiss.

That feedback is valuable. Over time you can learn which recommendations editors accept and suppress bad patterns.

Don't make the recommendation engine purely SEO-driven

This is particularly important for a publisher.

The system shouldn't think:

"These pages are similar, therefore link them."

Instead:

"This link is useful to a reader at this point in the article, and it also strengthens the site's topical architecture."

Google's guidance emphasizes useful, crawlable site structures, while its spam policies specifically warn against creating low-value content or links primarily to manipulate rankings. Google for Developers

One feature I'd prioritize unusually highly: orphan detection

For a large publisher, I'd maintain a graph containing:

• URL
• publication date
• last update
• topic/entity IDs
• inbound internal links
• outbound internal links
• organic traffic
• impressions
• index status
• canonical URL
• content type
• author/section

Then surface things like:

High-value orphan pages

• 12,000 indexed pages
• 430 have ≤1 internal link
• 76 have meaningful search traffic
• 23 are important evergreen pages

That gives your editorial/SEO team a much better workflow than manually auditing thousands of URLs.

Make your linking architecture template-driven

At scale, I would use three layers:

1. Structural links

Navigation, breadcrumbs, category pages, author pages, topic pages, etc.

2. Contextual links

The intelligent recommendations described above.

3. Automated related-content modules

For example:

• "More on this topic"
• "Related"
• "Read next"
• "From the archive"
• "Latest from [topic]"

The important part is that these modules should be controlled by your topic/entity model, rather than simply displaying "5 articles with similar keywords."

Breadcrumbs can also help Google understand page categorization; Google documents BreadcrumbList as supported structured data. Google for Developers

Technical features I'd put underneath all of this

For a large publisher, I'd make sure your platform has:

• Automatic XML sitemaps, preferably segmented by content type/date.
• Accurate lastmod values.
• Canonical URL management.
• Redirect management.
• 404/410 monitoring.
• Pagination/archives handled deliberately.
• Faceted/filter URL controls where applicable.
• Crawlable HTML <a href> links.
• Consistent internal URLs.
• Automated detection of redirect chains.
• Indexability controls.
• Search Console integration.
• Server-log analysis if you have the infrastructure.

Google specifically recommends sitemaps as a way to help discovery and provides guidance around crawl-budget management for large sites. Google for Developers Google for Developers

If resources are limited

I'd build the roadmap as:

Phase 1

• Topic/entity taxonomy
• Internal-link recommendation engine
• Orphan-page report
• Automated related-content blocks
• Sitemap/canonical/indexation hygiene

Phase 2

• Editorial feedback loop for recommendations
• Broken-link detection
• Link-graph visualization
• Destination/link saturation controls
• Search Console + analytics integration

Phase 3

• Predictive recommendations
• Automatic detection of emerging topics
• Content-cluster gap analysis
• Automated refresh/linking suggestions for aging content

The key architectural decision is to build a content graph rather than an SEO checklist. Once every URL is connected to topics, entities, intent, freshness, importance, and existing links, you can power internal linking, orphan detection, content hubs, related stories, archive pages, and eventually content-gap analysis from the same underlying system.

For a mid-size publisher with lots of URLs, I’d prioritize SEO features that improve crawlability, information architecture, indexation control, and scalable internal linking before chasing individual SERP enhancements.

Priority order

Google explicitly notes that breadcrumbs can help users understand and navigate site hierarchy, and its current Search documentation supports Article, Breadcrumb, Organization, ProfilePage and other structured-data types. Google for Developers Google for Developers

The internal-linking system I'd build

The big opportunity is not simply "add related articles." I'd make internal linking an actual graph.

For every article, maintain signals such as:

• Topic/entity IDs
• Primary category
• Secondary categories
• Publication date
• Recency/decay
• Editorial importance
• Search traffic
• Impressions
• Links in / links out
• Content type
• Geographic relevance
• Author
• Semantic similarity

Then generate candidate links using roughly:

candidate relevance × editorial relevance × freshness × site value × link deficit

with hard constraints to avoid:

• linking to the same URL repeatedly
• linking hundreds of times to a single page
• recommending essentially duplicate articles
• creating circular "related story" networks
• stuffing exact-match anchor text
• linking to low-value/noindex pages

Particularly valuable: link deficits

Instead of asking:

"What articles are similar to this article?"

also ask:

"Which important pages on our site currently need more contextual links?"

That lets you deliberately move authority toward pages that matter.

For example:

                   [Climate Change Hub]
                    /       |       \
                   /        |        \
          [Explainer]   [Latest]   [Data]
              /  \          |
             /    \         |
        [Story A] [Story B] [Story C]

New articles can automatically link upward to the hub, sideways to highly relevant evergreen material, and potentially downward to specific supporting stories.

That is much more scalable than treating every article as an isolated document.

I'd also make "orphan detection" a first-class feature

Have a daily/weekly job produce something like:

URL                  Inlinks   Organic clicks   Priority
---------------------------------------------------------
article-A               0           420             HIGH
article-B               1           180             HIGH
article-C               7            12             MEDIUM
article-D              43           900             LOW

The first two are particularly interesting: they're receiving search traffic despite weak internal connectivity.

Conversely, a page with 200 internal links isn't necessarily healthy. You want to identify structural outliers, not optimize toward a universal link-count target.

Don't underestimate indexation controls

At publisher scale, automated linking can actually make a bad architecture worse if you're generating huge numbers of thin/duplicative URLs.

I'd give the CMS explicit controls for:

• canonical URL
• index/noindex
• sitemap inclusion
• pagination/archive behavior
• tag/category indexing
• parameter handling
• redirect status
• content expiration
• duplicate/near-duplicate detection

Google notes that when substantially similar URLs exist, it clusters them and selects a canonical, with canonicalization signals including redirects, sitemaps and rel="canonical". Google for Developers

One feature I'd build that publishers often miss

"Link opportunities" in the CMS

When an editor is writing:

"The Federal Reserve raised interest rates..."

the editor sees:

Internal link opportunities

• Federal Reserve explained — 92% relevance
• Interest rates timeline — 87%
• How the Fed sets rates — 84%
• Previous Fed decision — 81%

But don't automatically insert all of them.

Give the editor a one-click accept/reject mechanism, and learn from those decisions. That gives you human editorial judgment while still getting most of the scalability of automation.

For evergreen content, you can eventually automate more aggressively; for news, I'd keep editorial control considerably stronger.

My rough roadmap

Phase 1 — foundation

• Clean canonicalization
• XML sitemaps
• Breadcrumbs/taxonomy
• Crawl/index monitoring
• Orphan detection
• Broken-link detection

Phase 2 — linking engine

• Entity/topic extraction
• Related-content recommendations
• Hub ↔ article relationships
• Link-deficit scoring
• Anchor-text suggestions
• CMS/editor integration

Phase 3 — optimization loop

• Measure internal links → discovery/indexation/traffic
• Identify underlinked high-value pages
• Detect overlinked pages
• Refresh stale links when stories become outdated
• Continuously improve recommendation relevance

Phase 4 — structured data / search appearance

• Article
• Breadcrumb
• Organization
• ProfilePage where appropriate
• Other schema types that genuinely describe your content

The key architectural decision I'd make is to treat your internal-link graph as a first-class data product, rather than making "related stories" a presentation-layer widget. That gives you something you can analyze, score, audit, and continuously improve across hundreds of thousands—or eventually millions—of URLs.

For evergreen content, you can eventually automate more aggressively; for news, I'd keep editorial control considerably stronger.

My rough roadmap

Phase 1 — foundation

• Clean canonicalization
• XML sitemaps
• Breadcrumbs/taxonomy
• Crawl/index monitoring
• Orphan detection
• Broken-link detection

Phase 2 — linking engine

• Entity/topic extraction
• Related-content recommendations
• Hub ↔ article relationships
• Link-deficit scoring
• Anchor-text suggestions
• CMS/editor integration

Phase 3 — optimization loop

• Measure internal links → discovery/indexation/traffic
• Identify underlinked high-value pages
• Detect overlinked pages
• Refresh stale links when stories become outdated
• Continuously improve recommendation relevance

Phase 4 — structured data / search appearance

• Article
• Breadcrumb
• Organization
• ProfilePage where appropriate
• Other schema types that genuinely describe your content

The key architectural decision I'd make is to treat your internal-link graph as a first-class data product, rather than making "related stories" a presentation-layer widget. That gives you something you can analyze, score, audit, and continuously improve across hundreds of thousands—or eventually millions—of URLs.

For a mid-size publisher with large content volumes, I’d prioritize SEO features that automate content discovery, internal authority flow, and crawl/indexation control rather than a long checklist of on-page fields.

My priority order

The internal-linking system I'd build

Don't make this just a "related articles" widget.

Build a recommendation engine that scores potential links something like:

Link score = semantic relevance × destination value × topical relationship × freshness × editorial confidence − duplication/overlinking penalty

For each article, give the editor something like:

Recommended internal links

• “How the Fed sets interest rates” → strong contextual match
• “What inflation means for consumers” → strong contextual match
• “2026 inflation outlook” → medium match, very fresh

Suggested anchor: how the Fed sets interest rates

The important distinction is that you're recommending links into your site's information architecture, not merely recommending articles a reader might click.

Google says it uses links to discover pages and understand relevance, and that the relationship between pages—including the number of links pointing to a page—can help it infer relative importance. Google for Developers Google for Developers

I'd also have the system work in the reverse direction

For every new article:

1. Find the best existing pages it should link to.
2. Find existing pages that should now link to it.
3. Identify a suitable anchor/context for each.
4. Flag potentially redundant links.
5. Monitor whether the new article actually acquired those links.

That second step is particularly valuable for publishers. Otherwise every new story starts life as an isolated node and has to wait for an editor to discover it.

The feature I'd avoid overinvesting in

A generic AI "related stories" module.

It's easy to build and looks impressive, but it's not necessarily solving your biggest SEO problem.

I'd instead build an SEO content graph underneath it. Then you can use that same graph for:

• contextual internal links
• related-story modules
• topic hubs
• pillar-page recommendations
• orphan detection
• content consolidation
• cannibalization detection
• editorial briefs
• "update this article" recommendations
• sitemap prioritization

That gives you one piece of infrastructure powering multiple SEO/editorial products.

One particularly important publisher feature

I'd add link equity / importance visualization.

For example:

Politics
   ↓
US Elections
   ↓
2026 Midterms
   ├── Pennsylvania Senate Race
   ├── Governor Races
   ├── House Control
   └── Election Calendar

Then show editors:

• pages with 0 inbound internal links
• pages with only 1 inbound link
• important pages buried several levels deep
• high-authority pages that could pass relevance to important destinations
• topics with lots of content but no clear hub
• articles that are accumulating links but aren't actually your strategic pages

This is much more useful at 100,000+ URLs than manually checking title tags.

If resources are limited

I'd ship these five things first:

1. Semantic internal-link recommendation engine
2. Orphan/underlinked-page detection
3. Inbound/outbound link reporting
4. Automated canonical + sitemap management
5. Topic/entity content graph

Then add automated insertion only after editors trust the recommendations.

And I'd keep the links as normal crawlable <a href> links rather than relying on JS interactions; Google explicitly recommends crawlable anchors for discovery. Google for Developers

Bottom line: for a mid-size publisher, I'd spend substantially more engineering effort on content graph + internal linking + crawl/indexation controls than on another collection of traditional "SEO fields." Those systems compound as your archive grows, which is exactly what you want at publisher scale.

Then add automated insertion only after editors trust the recommendations.

And I'd keep the links as normal crawlable <a href> links rather than relying on JS interactions; Google explicitly recommends crawlable anchors for discovery.

For a mid-size publisher with a large and constantly growing content corpus, I’d prioritize SEO features that create systematic gains across thousands of URLs, rather than one-off on-page optimization tools.

My priority order

1. Build the internal-link recommender first

I'd make this much more sophisticated than "find pages containing the same keyword."

For every article, generate recommendations based on:

• Semantic similarity between source and destination
• Topic/entity relationships
• Destination's organic traffic/impressions
• Destination's importance to the business
• Existing internal-link count
• Whether the destination is orphaned or underlinked
• Whether the source already links to that destination
• Anchor-text diversity
• Freshness/recency
• Search intent compatibility
• Distance between pages in your topic taxonomy

The output should look something like:

Add link: "Federal Reserve interest-rate decision"
Destination: "What the Fed funds rate means for mortgages"
Suggested anchor: "how the Fed funds rate affects mortgage rates"
Confidence: 94%
Reason: Same topic cluster; destination has high search value but only 3 internal links.

That last part is important: optimize the link graph, not just the number of links.

Google explicitly emphasizes descriptive anchor text and uses internal links to discover pages; for large sites, ensuring important pages are actually reachable is particularly important. Google for Developers Google for Developers

2. Add a "link equity" / underlinking model

This is probably the highest-value feature after recommendations.

Create a page-level score such as:

Link opportunity = page value × link deficit × contextual relevance

Then identify:

• High-value pages with very few internal links
• Pages receiving lots of links but contributing little value
• Important pages buried several clicks deep
• Topic hubs with weak supporting links
• Newly published pages that haven't acquired internal links
• Old pages whose internal links have disappeared as content gets updated

I'd give SEO editors a dashboard like:

127 pages need internal-link attention

23 high-priority
61 medium-priority
43 low-priority

This is much more actionable than an enormous list of keyword opportunities.

3. Make topic clustering a core data layer

Don't build the recommender directly on keywords.

Build an underlying graph:

Article → topics → entities → other articles → authors → sections → search queries

For example:

Mortgage rates
├── Federal Reserve
│   ├── Fed funds rate
│   ├── FOMC
│   └── inflation
├── Mortgage types
│   ├── 30-year fixed
│   ├── ARM
│   └── FHA
└── Consumer impact
    ├── monthly payments
    ├── refinancing
    └── home affordability

Then your linker can recognize that an article about an FOMC decision might naturally link to several different mortgage explainers—even if the exact keywords don't overlap.

4. Automatically link new content into the existing corpus

This is where publishers can get enormous leverage.

When an editor publishes:

1. Extract entities/topics from the new article.
2. Find the 10–30 most relevant existing pages.
3. Rank link opportunities.
4. Suggest 3–5 contextual links.
5. Identify 1–3 older pages that should link back to the new article.
6. Surface the recommendations inside the CMS.

That last step is especially valuable. Internal linking shouldn't be a post-publication SEO project.

5. Don't overlook orphan-page detection

Have a crawler/database continuously classify URLs:

• Orphaned
• 1 internal link
• 2–5 links
• Well-linked
• Hub
• High-authority hub

Then intersect that with Search Console data.

A page with:

10,000 impressions + 1 internal link

is much more interesting than:

10 impressions + 1 internal link.

You want your system prioritizing the former.

6. Canonical + indexation controls are your scalability safety net

As publishing volume increases, the bigger danger isn't necessarily "not enough SEO."

It's too many URLs:

• Tags
• Search pages
• Pagination variants
• Author archives
• Date archives
• Filters
• Parameters
• Duplicate stories
• Syndicated content
• Near-duplicate updates

So I'd build strong CMS-level controls for canonicalization, noindex, robots directives, pagination/archives, and sitemap inclusion.

This becomes increasingly important as your URL inventory grows.

7. Structured data: automate it, but don't put it ahead of linking

Have templates for the schema types that genuinely describe your content—Article, Breadcrumb, ProfilePage, etc.—and validate them automatically.

Breadcrumbs are particularly useful for publishers because they communicate the page's position in the site's hierarchy. Google for Developers

But I wouldn't spend engineering resources building elaborate schema tooling before fixing your crawlability + internal-link architecture.

Google also makes clear that structured data can help it understand content and enable certain search appearances, but it doesn't guarantee that a rich result will appear. Google for Developers

The feature I'd build as your "killer" publisher SEO product

I'd combine everything into an Internal Linking Intelligence Engine:

                    CONTENT CORPUS
                         │
          ┌──────────────┴──────────────┐
          ↓                             ↓
   Topic/entity graph             Search data
          │                    (GSC + rankings)
          └──────────────┬──────────────┘
                         ↓
               LINK OPPORTUNITY MODEL
                         │
          ┌──────────────┼──────────────┐
          ↓              ↓              ↓
       Add link     Orphan page     Update link
          │              │              │
          └──────────────┼──────────────┘
                         ↓
                    CMS ACTION

And give editors recommendations rather than reports.

The key metric I'd optimize for isn't "number of links created." It's something like:

Organic impressions/traffic gained per 1,000 internal-link changes

That lets you determine whether the recommendation engine is actually moving the needle.

If resources are limited, my 80/20 would be:
(1) contextual internal-link recommendations → (2) orphan/underlinked detection → (3) automated linking on publication → (4) topic/entity graph → (5) canonical/indexation controls.

That combination should have substantially more leverage for a mid-size publisher than investing first in dozens of individual title/meta/keyword optimization features.

6. Canonical + indexation controls are your scalability safety net

As publishing volume increases, the bigger danger isn't necessarily "not enough SEO."

It's too many URLs:

• Tags
• Search pages
• Pagination variants
• Author archives
• Date archives
• Filters
• Parameters
• Duplicate stories
• Syndicated content
• Near-duplicate updates

So I'd build strong CMS-level controls for canonicalization, noindex, robots directives, pagination/archives, and sitemap inclusion.

This becomes increasingly important as your URL inventory grows.

7. Structured data: automate it, but don't put it ahead of linking

Have templates for the schema types that genuinely describe your content—Article, Breadcrumb, ProfilePage, etc.—and validate them automatically.

Breadcrumbs are particularly useful for publishers because they communicate the page's position in the site's hierarchy.

For a mid-size publisher with a large content library, I’d prioritize features that improve crawlability, content discovery, topical authority, and editorial efficiency—not a giant checklist of on-page SEO fields.

My priority order

Google explicitly emphasizes crawlable links and has separate guidance around crawl-budget management for large sites; it also notes that duplicate URLs are crawled less frequently than canonical versions. Google for Developers Google for Developers

The internal-linking system I'd build

The key is recommendation quality over link quantity.

For every article, calculate candidate links using something like:

Recommendation score = semantic relevance × business/search value × freshness × link equity opportunity × editorial fit

Then expose recommendations such as:

Add link: “2026 mortgage rate outlook”
From: “How mortgage rates affect home prices”
Anchor: “mortgage rate outlook”
Why: Highly related topic; destination has strong search demand but only 3 internal links.

Particularly valuable signals

• Semantic similarity: embeddings/entity relationships rather than exact keyword matching.
• Topic hierarchy: article → subtopic → broader topic → evergreen hub.
• Search performance: prioritize destinations with impressions but relatively weak rankings.
• Internal-link authority: identify pages with strong inbound internal links that can pass relevance to newer/important pages.
• Recency: news/current-affairs content should preferentially link to authoritative evergreen explainers, while evergreen pages should surface relevant recent coverage.
• Existing-link awareness: don't recommend links that already exist.
• Anchor diversity: prevent the system from generating the same exact anchor text everywhere.
• Editorial context: recommend links that genuinely help the reader answer the question they're currently reading.

I'd also create a "link this page to..." workflow at publication time. That lets every new article immediately connect to your existing corpus instead of waiting for a periodic SEO audit.

Don't make it fully automatic

For a publisher, I'd use:

AI recommends → editor approves → CMS publishes → system measures → model improves.

That is much safer than automatically inserting dozens of links.

Google's spam guidance specifically warns against low-value content and manipulative linking practices, so the system should optimize for useful navigation rather than maximizing the number of internal links. Google for Developers Google for Developers

The feature I'd consider a killer differentiator

Build an Internal Linking Opportunity Dashboard rather than just an inline recommendation widget.

For each URL, show:

• Inbound links: 2
• Recommended inbound links: 14
• Orphan risk: High
• Search impressions: 84K/month
• Ranking opportunity: High
• Best 5 source pages: ranked by relevance
• Best destination/hub: identified automatically
• Missing topic relationships: e.g. article covers "mortgage rates" but isn't connected to the mortgage hub
• Last updated: 11 months ago

Then give SEO editors a queue:

Fix these 25 pages first — estimated highest impact

That turns internal linking from an SEO audit into an ongoing editorial workflow.

For large content volumes, also prioritize URL hygiene

Before investing heavily in sophisticated recommendations, make sure your platform handles:

• Canonical URLs
• Noindex rules
• Pagination
• Faceted/filter URLs
• Duplicate/near-duplicate content
• Redirects
• XML sitemaps
• Stale/expired articles
• 404/410 handling
• Crawlable HTML links

This matters because at publisher scale, the problem can become "Google has too many URLs to process", rather than simply "we need more links." Google's current documentation specifically calls out crawl-budget and faceted-navigation management for large sites. Google for Developers

If I had to pick only 5 features

1. Semantic internal-link recommendation engine
2. Orphan + underlinked-page detection
3. Topic/entity graph
4. Internal-link opportunity/prioritization dashboard
5. Automated sitemap/canonical/indexability management

I'd put AI title/meta generation, keyword scoring, and generic SEO checklists behind those. For a mid-size publisher, the differentiated value is much more likely to come from understanding the entire content graph and continuously improving its connections than from generating another SEO title.

• Canonical URLs
• Noindex rules
• Pagination
• Faceted/filter URLs
• Duplicate/near-duplicate content
• Redirects
• XML sitemaps
• Stale/expired articles
• 404/410 handling
• Crawlable HTML links

This matters because at publisher scale, the problem can become "Google has too many URLs to process", rather than simply "we need more links." Google's current documentation specifically calls out crawl-budget and faceted-navigation management for large sites.

If I had to pick only 5 features

For a mid-size publisher with a large content library (thousands to hundreds of thousands of URLs), I’d prioritize SEO features that create repeatable systems, not one-off optimization workflows. Internal linking is especially valuable at scale because it helps distribute authority, improve discovery, and connect related content clusters. Ahrefs Search Engine Journal

A practical priority order:

1. Automated internal link recommendations (highest priority)

Look for a system that can recommend links based on:

• Semantic similarity (topic/entity understanding, not just keyword matching)
• Search intent overlap
• Existing rankings (e.g., pages ranking positions 5–30 that need support)
• Traffic/value potential
• Content freshness
• Editorial importance

The ideal workflow:

“Article A should link to Article B because they cover related entities, Article B is underperforming, and Article A has authority.”

Avoid simple “find this keyword and insert a link” automation; it creates irrelevant anchors and poor UX. Andava

Key features:

• Suggested source page
• Suggested destination page
• Suggested anchor text
• Confidence score
• Estimated impact
• One-click editorial approval

2. Internal linking gap analysis

You want dashboards that answer:

• Which important pages have too few internal links?
• Which pages receive too many links?
• Which new articles are orphaned?
• Which evergreen content is losing internal support?

Useful reports:

Large sites often need this because manual linking stops working once content volume grows. DataDab

3. Topic cluster / content graph modeling

For publishers, I would prioritize a knowledge graph view over a basic sitemap view.

Example:

Hub: Climate change
→ Renewable energy
→ Solar power
→ Battery storage
→ Grid modernization
→ Policy updates

Your system should understand:

• Entities
• Topics
• Authors
• Series
• Related stories
• Historical coverage
• Updates/revisions

Then recommendations become editorially meaningful:

“This new election analysis should link to your previous candidate profile, voting guide, and policy explainer.”

4. New content publishing guardrails

Make SEO part of the publishing workflow.

Before an article goes live:

• Recommend 3–5 existing articles to link to
• Suggest 2–3 future articles that should link back
• Check if the topic already exists
• Identify possible cannibalization
• Generate metadata recommendations
• Validate structured data

This prevents the common publisher problem: publishing thousands of articles that become isolated over time. Search Engine Journal

5. Content decay monitoring

For publishers, this is usually higher ROI than creating more content.

Track:

• Traffic decline
• Ranking decline
• Lost impressions
• Declining internal links
• Outdated references
• Competitor content growth

Then trigger actions:

• Refresh article
• Add newer links
• Merge duplicates
• Redirect obsolete pages
• Strengthen topic hubs

6. Crawl and index management

Large publishers should invest heavily here.

Prioritize:

• Crawl diagnostics
• Index coverage monitoring
• Duplicate detection
• Parameter control
• Canonical management
• XML sitemap automation
• Archive/page lifecycle rules

At scale, technical problems are often template or system problems rather than individual page problems. Semrush

7. Editorial SEO analytics

Give editors visibility without making them SEO specialists.

Useful views:

• “Articles gaining momentum”
• “Articles that need internal links”
• “Topics where we have authority”
• “Topics where competitors outperform us”
• “High-value pages losing rankings”

Features I would not prioritize early

Lower ROI for a mid-size publisher:

• Fully automatic link insertion with no review
• AI-written content optimization at scale
• Generic keyword density scoring
• Vanity SEO scores
• Large keyword databases without workflow integration

A good MVP roadmap

Phase 1 (0–3 months)

• Internal link recommendations
• Orphan page detection
• Broken link monitoring
• Publishing workflow integration

Phase 2 (3–6 months)

• Topic/entity graph
• Content decay alerts
• Editorial dashboards
• Automated refresh recommendations

Phase 3 (6–12 months)

• Predictive recommendations
• Experimentation framework
• Personalized recommendations by section/author/team

For a mid-size publisher, the biggest win is usually a recommendation engine that combines content understanding + ranking data + editorial workflow, rather than simply buying a crawler. Internal linking recommendations are one of the areas where automation can create measurable leverage. Ahrefs searchengineland.com

For a mid-size publisher with large content volumes, I’d prioritize SEO features that create a repeatable content graph rather than one-off optimization. Internal linking is usually the biggest scalable lever because you already own the inventory of pages and can redistribute authority and discovery paths. Ahrefs Search Engine Land

A practical priority order:

1. Automated internal link recommendations (highest priority)

Build or buy a system that recommends:

• Source page → target page pairs
• Suggested anchor text
• Confidence/relevance score
• Expected impact (traffic opportunity, ranking lift, orphan-page recovery)

The best recommendations should combine:

• Semantic similarity (same topic/entity)
• Search performance (pages ranking positions 5–30 are great targets)
• Business importance (evergreen hubs, revenue pages, newsletters, subscriptions)
• Link authority flow (strong pages supporting weak pages)
• Freshness signals (new articles needing discovery)

Avoid simple keyword matching. It creates bad links (for example, linking every occurrence of “apple” to a technology article when the page is about fruit).

2. Content graph / topic cluster management

For publishers, think in entities and topics:

Example:

Hub: “Climate Change”

• Causes of climate change
• Climate policy timeline
• Renewable energy explainers
• Extreme weather coverage
• Climate science interviews

Your SEO system should understand:

• Which pages are hubs
• Which pages are supporting articles
• Which topics are under-covered
• Which pages are competing with each other

This helps prevent thousands of articles from becoming disconnected islands.

3. Internal link auditing dashboard

Must-have reports:

Orphan content

Pages with:

• No internal links
• Only sitemap discovery
• Low crawl frequency

Underlinked winners

Pages that:

• Already rank
• Get impressions
• Have few internal links

Link equity leaks

Find:

• Too many links pointing to outdated pages
• Broken internal links
• Redirect chains
• Dead sections of the archive

Large sites benefit from continuous auditing because link structures degrade as content grows. Search Engine Journal

4. CMS publishing integrations

Put SEO into the workflow, not after it.

Before publishing, require:

• Related articles selected
• Canonical checked
• Schema selected
• Category/topic assigned
• Minimum internal link recommendations reviewed

A good workflow might say:

“This article has 0 links to authoritative existing coverage. Suggested additions: 5.”

5. Entity and taxonomy management

Publishers often have messy archives:

• “Taylor Swift”
• “Taylor Swift news”
• “Taylor Swift interview”
• “Taylor Swift biography”

A strong SEO system should map these to one entity/topic and understand relationships.

Useful features:

• Entity extraction
• Topic clustering
• Duplicate/cannibalization detection
• Taxonomy cleanup recommendations

6. Content decay detection

Prioritize updates automatically:

Flag articles that:

• Lost rankings
• Lost traffic
• Have outdated statistics
• Have broken outbound links
• Are being outranked by newer competitors

Then recommend:

• Update content
• Add links to newer coverage
• Merge with another article
• Redirect/archive

7. Crawl and index management

For large publishing sites, include:

• Crawl budget monitoring
• Index coverage monitoring
• Parameter control
• Duplicate-content detection
• Pagination/archive controls
• XML sitemap automation

8. Measurement layer

Track internal linking impact, not just link counts.

Useful metrics:

• Rankings gained after receiving internal links
• Organic clicks to newly linked pages
• Crawl frequency changes
• Pages moving from positions 11–50 into page one
• Traffic recovered from stale content

Suggested roadmap

First 90 days

1. Internal link crawler
2. Orphan-page detection
3. Link recommendation engine
4. CMS integration
5. Topic/entity tagging

3–6 months

1. Automated suggestions at scale
2. Content decay workflows
3. Cannibalization detection
4. Editorial dashboards

6–12 months

1. Predictive SEO scoring
2. AI-assisted briefs
3. Automated content graph optimization

For a mid-size publisher, I would spend less effort on “SEO score” features and more on link graph intelligence + editorial workflow integration. The winning system is one that helps editors publish better-connected content every day, not one that produces another audit report. Search Engine Land andava.com

For a mid-size publisher with lots of URLs, I’d prioritize SEO features that improve discovery, internal authority distribution, index quality, and editorial efficiency—rather than spending heavily on SERP bells and whistles.

My priority order

1. Build an internal-link recommendation engine

This would be my #1 feature investment.

Don't make it simply:

"This article contains the phrase climate change, so link to /climate-change/."

Instead, score candidate links using several signals:

Recommendation score = topical relevance × destination value × link need × freshness × confidence

For example:

• Semantic similarity: Are the two articles genuinely about the same subject?
• Entity overlap: Same person, organization, place, event, topic, etc.
• Search intent: Does the destination answer a natural follow-up question?
• Destination importance: Is this an evergreen page you want to strengthen?
• Current internal links: Does the destination already have 500 links?
• Source importance: Is the linking article itself authoritative/popular?
• Recency: Is this a newly published article that needs discovery?
• Anchor quality: Can the link use a natural, descriptive phrase?

Google explicitly emphasizes crawlable links and site structure, and for large sites the way pages are interconnected can affect how efficiently new content is discovered. Google Developers

2. Make "link equity gaps" a first-class feature

I'd want a dashboard like:

Pages needing internal links

47 high-value articles have fewer than 3 relevant internal links.

12 have zero contextual inbound links.

8 important evergreen pages receive most of their links only from navigation.

Then prioritize opportunities rather than dumping 100 recommendations on editors.

For example:

High opportunity

Article A → Evergreen Guide B

• relevance: 94%
• destination organic traffic: 18k/mo
• current inbound internal links: 3
• recommended anchor: "how the Fed sets interest rates"

That's considerably more actionable than "add internal links."

3. Use topic/entity graphs underneath the recommendations

For a publisher, I'd invest in an underlying content graph.

Nodes:

• articles
• authors
• topics
• people
• organizations
• places
• events
• evergreen guides
• categories

Edges:

• discusses
• updates
• contradicts
• follows
• related to
• same entity
• same topic

This allows recommendations such as:

"This breaking-news article should link to your existing 2024 explainer."

rather than relying purely on lexical similarity.

It also gives you a natural way to create topic hubs and identify areas where coverage is fragmented.

4. Automate links at the template level—but carefully

I'd have two systems:

Editorial links

Human-approved contextual links inside articles.

Programmatic links

Rules such as:

• article → canonical topic page
• article → author page
• article → relevant evergreen guide
• article → entity page
• article → previous installment in a series

The key is not to automatically plaster dozens of links onto every page. Google warns against low-quality/keyword-manipulative linking practices, so relevance and usefulness should drive the system. Google Developers

A good system might recommend 3–8 highly relevant links, not 40 mediocre ones.

5. Put orphan detection next to link recommendations

These should really be one product.

I'd segment URLs into:

• Orphan: zero internal inbound links
• Underlinked: fewer than your threshold
• Well linked
• Overlinked: disproportionately many links relative to importance

Then combine this with business/search data:

"14 high-traffic articles are underlinked."

is much more useful than:

"1,842 pages have fewer than five internal links."

6. Make indexability/canonical management extremely robust

At publisher scale, URL hygiene becomes SEO infrastructure.

Prioritize controls for:

• canonical URLs
• duplicate articles
• pagination
• tag/category pages
• author pages
• search pages
• faceted URLs
• expired/dead content
• parameter URLs
• syndicated content
• redirects
• 404/soft-404 detection

Google notes that duplicate URLs can increase crawling overhead and that canonical pages are generally crawled more regularly than duplicates. Google Developers

This is especially important if your CMS can generate thousands of URLs automatically.

7. Treat sitemaps as an automated SEO system

Don't just have:

/sitemap.xml

Have intelligently segmented sitemaps, e.g.:

• news/current content
• evergreen articles
• video
• sections/categories
• recently updated content

And automatically remove URLs that shouldn't be indexed.

Google recommends keeping sitemap URLs canonical and provides mechanisms for automating sitemap submission. Google Developers

8. Add content decay/refresh detection

For publishers, this can be more valuable than another metadata optimizer.

Flag articles where:

• organic clicks are declining
• rankings are declining
• impressions remain high but CTR is falling
• competitors have overtaken you
• facts/data are outdated
• newer articles cannibalize the old article
• the article has strong backlinks but stale content
• the article has weak internal links despite strong external authority

Then connect that directly to linking:

"Update this article and link it to these 5 newer stories."

That creates a continuous publish → link → refresh → consolidate loop.

9. Measure internal linking like a growth channel

I'd want reporting around:

• internal links added
• clicks on internal links
• pages discovered after links were added
• indexing rate
• organic sessions
• rankings
• traffic passed to destination pages
• orphan rate
• average inbound links/page
• links to priority evergreen pages

The important distinction is between "we generated 10,000 links" and "10,000 links produced measurable SEO/user value."

What I would not prioritize

I wouldn't make these your first big investments:

• AI-written meta descriptions
• AI-generated titles at scale
• generic keyword-density analysis
• automated FAQ generation
• massive keyword inventories
• bulk AI content generation
• generic "SEO score: 87/100" dashboards

Especially for publishers, scaling content without maintaining distinct user value can create quality problems; Google's current spam guidance explicitly addresses scaled content abuse. Google Developers

If I had 6 months of engineering capacity

I'd roughly allocate it:

1. 30% — Internal-link recommendation engine

• semantic/entity matching
• destination scoring
• anchor suggestions
• editor workflow
• 20% — Site graph + orphan/underlinked detection

• crawl graph
• inbound/outbound link analysis
• topic clusters
• 20% — Indexation infrastructure

• canonicals
• redirects
• noindex rules
• sitemap automation
• duplicate detection
• 15% — Content decay/refresh

• traffic/ranking changes
• freshness
• cannibalization
• refresh recommendations
• 10% — Measurement

• internal-link experiments
• Search Console/analytics integration
• SEO impact reporting
• 5% — Structured data/metadata automation

The strategic idea

For a mid-size publisher, I would build an SEO content graph, not an "SEO checklist."

The graph should continuously answer four questions:

What should we publish? → What should it link to? → What needs more authority? → What old content needs updating/consolidating?

That architecture scales much better than giving editors another SEO plugin with 30 individual recommendations.

For a mid-size publisher, I’d prioritize SEO features that scale through your CMS and information architecture, rather than adding more one-off on-page controls.

My priority order

Google specifically recommends updating internal links when URLs change, and its current documentation emphasizes using your CMS, Search Console and server data to understand your site's URL/link structure. Google for Developers Google for Developers

1. Make internal linking your biggest investment

I'd build a recommendation engine, not just a "related articles" widget.

For every new or updated article, generate something like:

• 3–5 highly relevant contextual links to insert into the body
• 3–5 supporting articles for a "Read more" module
• 1–2 authoritative hub/topic pages
• 1–2 newer articles that should receive a link from older content
• warnings for orphaned or under-linked important URLs

The key is to score candidates using multiple signals:

semantic similarity + entity overlap + topical relationship + search importance + freshness + editorial section + existing link graph

Don't make keyword matching the core system. A publisher can easily end up with dozens of pages that all mention "Taylor Swift" but aren't actually the best contextual link for one another.

Also put a cap on automated links. You want useful navigation, not every article linking to 30 other articles. Google explicitly considers excessive/low-quality linking and automated link creation problematic when done primarily to manipulate rankings. Google for Developers

2. Build a topic/entity graph underneath it

This is probably the most important architectural decision.

Instead of:

Article → similar articles

build:

Article → entities → topics → related articles → authoritative hubs

For example:

Article: "How the Fed's September decision affects mortgages"

Could connect to:

• Federal Reserve
• interest rates
• mortgages
• inflation
• housing
• September 2026 Fed meeting

That lets your system recommend links that are conceptually useful, even when the exact words don't overlap.

It also enables much better editorial tooling: "We have 184 articles about this topic, but only 23 link to the main explainer."

3. Prioritize orphan and under-linked pages

For publishers, I'd make this a dashboard:

Important pages with insufficient internal links

Rank URLs by something like:

organic traffic potential × importance × freshness × business value ÷ internal-link strength

Then give editors actionable recommendations:

This article has 2 internal links. We found 7 relevant articles that could link to it.

That's generally more valuable than simply reporting "you have 14,238 broken links."

4. Automate indexation controls

Large content volumes make URL hygiene disproportionately important.

Your CMS should make it easy to control:

• canonical URLs
• noindex
• pagination
• URL parameters
• tag/category archives
• author archives
• search pages
• duplicate/near-duplicate content
• expired/dead content
• syndicated content

Google notes that duplicate URLs can increase crawling burden and that canonicalization helps consolidate signals around the preferred URL. Google for Developers

5. Add a "content decay" engine

For a publisher, this can become a surprisingly high-value workflow.

Have the system identify:

• pages losing clicks/impressions
• rankings declining
• outdated statistics/dates
• old articles that still attract substantial traffic
• pages whose newer competitors have emerged
• articles receiving fewer internal links than they used to
• articles that should now link to newer coverage

Then surface:

Refresh candidate: 2024 article still gets 18K organic visits/month, but rankings for 6 major queries have declined 32%.

That creates a much better editorial SEO loop than endlessly producing new pages.

What I'd actually build first

If resources are limited, my roadmap would be:

Phase 1

1. Crawl/indexation inventory
2. Topic/entity extraction
3. Internal-link recommendation engine
4. Orphan-page detection
5. CMS editor integration

Phase 2

6. Content decay detection
7. Internal-link opportunity dashboard
8. Automated sitemap management
9. Template-level canonical/robots controls
10. Link-quality auditing

Phase 3

11. Editorial briefs
12. Automated refresh suggestions
13. Search-demand/topic-gap analysis
14. More sophisticated entity graphing

One important caveat: don't let the system's ability to generate pages become the SEO strategy. Google's current spam guidance specifically warns about scaled content created primarily to manipulate rankings, including large volumes of low-value AI-generated content. Google for Developers

So if you're deciding between "generate 50,000 more SEO pages" and "make the 500,000 pages we already have better connected, cleaner, fresher and easier to crawl", I'd strongly favor the latter for a mid-size publisher.

If you tell me roughly how many URLs you have, how many new articles/day, your CMS, and whether you're news/media vs. evergreen content, I can turn this into a concrete SEO feature roadmap + scoring algorithm for the internal-link recommender.

One important caveat: don't let the system's ability to generate pages become the SEO strategy. Google's current spam guidance specifically warns about scaled content created primarily to manipulate rankings, including large volumes of low-value AI-generated content.

Google notes that duplicate URLs can increase crawling burden and that canonicalization helps consolidate signals around the preferred URL.

5. Add a "content decay" engine

For a publisher, this can become a surprisingly high-value workflow.

Have the system identify:

For a mid-size publisher with large content volume, I’d prioritize SEO features that improve discovery, topical structure, index quality, and editorial efficiency—rather than a giant checklist of on-page fields.

My priority order

Google specifically emphasizes that internal links help discovery, and for larger sites crawlability/discovery becomes increasingly important. It also recommends keeping unnecessary URL variants under control. Google for Developers Google for Developers

1. Build internal linking as a recommendation system, not a "related articles" widget

This is where I'd spend the most product/engineering effort.

For every new or updated article, generate candidates based on:

• Semantic similarity — embeddings/entity similarity, not just matching keywords.
• Editorial taxonomy — section, topic, author, geography, subject, series, etc.
• Search intent — e.g. link a news article to an evergreen explainer when appropriate.
• Freshness — newer authoritative pages can be good destinations, but don't blindly prefer recent content.
• Page importance — prioritize linking toward pages you actually want to grow.
• Existing link graph — avoid recommending another link to a page that is already massively linked.
• Context — recommend links based on the paragraph where the link could naturally occur.

I'd give editors something like:

Recommended links

“What is a recession?” → 94% relevance
Suggested anchor: how recessions work
Reason: Explains the economic concept referenced in paragraph 4.

Then allow one-click insertion, rather than requiring editors to copy URLs.

The important distinction is that the system should optimize for useful connections in the content graph, not maximize the number of links. Google explicitly considers automated programs/services that create links for ranking manipulation problematic, so I'd keep recommendations editorially grounded and avoid mass-generated, keyword-stuffed linking. Google for Developers

2. Add a site-wide internal-link graph

Your SEO dashboard should answer:

• Which important pages have zero internal links?
• Which pages have hundreds/thousands of internal links?
• Which articles are receiving links from relevant topical neighbors?
• Which sections are effectively isolated?
• Which high-value pages are 4–5+ clicks from strong entry points?
• Which recently published pages haven't acquired internal links?
• Which old pages have strong external authority but weak internal connectivity?

I'd calculate an internal-link opportunity score per URL.

Something roughly like:

opportunity = page_value × relevance × link_deficit × discoverability_need

This is considerably more useful than a generic "SEO score."

3. Make taxonomy/entities first-class data

For a publisher, I'd avoid building internal linking around raw keywords alone.

Your CMS should know that:

Taylor Swift → person
Eras Tour → event/tour
Travis Kelce → person
NFL → organization/sport
Super Bowl → event

Then recommendations can connect content through entities and topics, even when the wording differs.

This also enables useful features like:

• topic hubs
• entity pages
• series pages
• "more on X" modules
• related explainers
• automatic breadcrumbs
• editorial knowledge graphs

4. Invest heavily in indexation controls

At scale, not creating bad URLs is almost as important as optimizing good ones.

Give editors/SEO teams controls over:

• tags
• author archives
• category combinations
• search pages
• filters
• pagination
• date archives
• duplicate/near-duplicate URLs
• parameterized URLs
• syndicated versions

Canonicalization is particularly important because Google clusters duplicate/similar URLs and selects a representative canonical URL; unnecessary URL variants can also increase crawling and complicate measurement. Google for Developers Google for Developers

5. Build "content decay" into the workflow

For publishers, this can be a killer feature.

Instead of simply telling an editor:

"Your SEO score is 72."

Tell them:

12 articles in your section are losing organic visibility.

• Article A: −38% clicks over 90 days
• Article B: ranking #8 → #17 for its primary query
• Article C: outdated statistics
• Article D: strong backlinks but no recent internal links

Recommended actions: update → consolidate → add links → leave alone

That turns SEO from a reporting function into an editorial prioritization system.

6. Automate the boring technical layer

At your scale, I'd want the platform automatically handling:

• canonicals
• redirects
• XML sitemaps
• lastmod
• breadcrumbs
• article structured data
• image metadata
• pagination/archives where applicable
• broken internal links
• orphan detection
• 404/410 monitoring
• duplicate title/H1 detection
• indexability monitoring

This should require very little editor intervention.

What I'd build first

If you have limited engineering capacity, my roadmap would be:

Phase 1

1. Internal-link graph
2. Contextual link recommendations
3. Orphan/underlinked-page detection
4. Automated sitemap/canonical/indexation controls
5. Broken-link monitoring

Phase 2

6. Entity/topic graph
7. Content decay detection
8. Refresh/consolidation recommendations
9. Editorial SEO dashboard
10. Link-performance measurement

Phase 3

11. Automated structured data
12. Advanced personalization/recommendations
13. Predictive content opportunities
14. Cross-section/topic authority analysis

One important caveat: don't make "AI content generation at scale" a major SEO feature. Google's current guidance explicitly distinguishes useful scaled editorial content from scaled content created primarily to manipulate rankings. Google for Developers

For a publisher, I'd rather have excellent content + an excellent content graph + excellent editorial tooling than 50 AI SEO buttons.

If you're evaluating this as a CMS/product roadmap, the single feature I'd bet on is context-aware internal-link recommendations backed by a site-wide content/entity graph. That's one of the few SEO capabilities that can improve thousands of existing URLs simultaneously.

1. Internal-link graph
2. Contextual link recommendations
3. Orphan/underlinked-page detection
4. Automated sitemap/canonical/indexation controls
5. Broken-link monitoring

Phase 2

6. Entity/topic graph
7. Content decay detection
8. Refresh/consolidation recommendations
9. Editorial SEO dashboard
10. Link-performance measurement

Phase 3

11. Automated structured data
12. Advanced personalization/recommendations
13. Predictive content opportunities
14. Cross-section/topic authority analysis

One important caveat: don't make "AI content generation at scale" a major SEO feature. Google's current guidance explicitly distinguishes useful scaled editorial content from scaled content created primarily to manipulate rankings.

Tell them:

For a mid-size publisher with large content volumes, I’d prioritize SEO features that automate content discovery, internal authority flow, and indexation hygiene rather than adding more on-page scoring.

My priority order

1. Automated internal-link recommendations — highest priority

• Recommend relevant links from new articles to existing articles.
• Also identify existing articles that should link to a newly published page—this is particularly valuable at scale.
• Score candidates using topic/entity similarity, search intent, freshness, page importance, and existing link relationships.
• Suggest useful, descriptive anchor text rather than exact-match anchors everywhere.
• Include guardrails: don't recommend links to redirects, canonicalized URLs, noindex pages, or low-value/archive pages.

Google explicitly recommends contextual internal links with descriptive anchor text and says important pages should have at least one internal link pointing to them. Google for Developers

2. Orphan-page + underlinked-page detection

Your system should continuously flag:

• Pages with zero internal links.
• Important pages with only 1–2 weak links.
• High-value pages buried many clicks deep.
• New articles that haven't acquired meaningful internal links after X days.
• Topic clusters with weak connections between cornerstone and supporting content.

This is arguably more important than simply generating "5 links to add to this article."

3. Topic/entity/content graph

Build a graph of:

article → topic → entity → related articles → category → author

Then use it for recommendations. A pure semantic-similarity engine tends to recommend "articles that sound similar"; a graph can recommend articles that are strategically useful.

For example:

"Best Medicare plans in Florida"
→ "Medicare Advantage"
→ "Medicare enrollment dates"
→ "Medicare Part B costs"
→ "Florida Medicare guide"

That lets you build intentional topical clusters rather than random semantic links.

4. Internal-link auditing at scale

Give SEO editors a dashboard showing:

• orphan URLs
• broken internal links
• redirected internal links
• links to noncanonical URLs
• pages with unusually high/low internal-link counts
• anchor-text distribution
• inbound links per URL
• click depth
• links from high-authority pages to important targets

Don't impose a simplistic "X links per article" rule. Google says there isn't a magical ideal number; relevance and usefulness matter. Google Developers

5. Automated XML sitemap management

For a publisher, this should essentially be invisible infrastructure:

• automatic sitemap generation
• sitemap splitting
• separate news/image/video sitemaps where applicable
• canonical URLs only
• recently updated/important content prioritized
• stale/deleted URLs automatically removed

Google currently recommends automatically generating larger sitemaps and supports up to 50,000 URLs or 50 MB per sitemap. Google for Developers

6. Indexation/canonical hygiene

At scale, I'd consider this a prerequisite for sophisticated linking recommendations:

• canonical validation
• noindex detection
• duplicate/near-duplicate detection
• redirect detection
• parameter/faceted URL controls
• soft-404 detection
• thin/low-value content identification

Otherwise your recommendation engine can spend enormous effort linking to pages you don't actually want indexed.

7. Freshness-aware recommendations

Publishers have an unusual advantage: new content constantly creates opportunities to update old content.

When a new article publishes, automatically find:

• older articles that should link to it
• older articles whose statistics/claims should be updated
• related evergreen pages that need a link
• outdated articles competing for the same query

I'd make this a prominent workflow rather than waiting for editors to discover it.

The feature I'd build first

If resources are limited, I'd build a "Link Opportunities" queue:

The important architectural decision is to make the recommendations bidirectional:

New page → pages it should link to
Existing pages → pages that should link to the new page

That second direction is where large publishers can get a lot of leverage.

One thing I wouldn't over-prioritize

I wouldn't spend much engineering effort on an elaborate "SEO score" for every article. A score telling an editor that an article is 87/100 is much less actionable than:

"These 4 pages should link to this article; these 3 links currently point through redirects; this article is orphaned; and this related evergreen page hasn't been updated in 14 months."

For large sites, Google also emphasizes that properly linked pages are generally discoverable, while sitemaps are especially useful for larger or more complex sites. Google for Developers Google for Developers

If I were ranking the roadmap:
1) bidirectional internal-link recommendations → 2) orphan/underlinked detection → 3) content graph → 4) link/indexation auditing → 5) automated sitemaps → 6) freshness/decay workflows → 7) editorial SEO scoring.

For a mid-size publisher with large content volumes, I’d prioritize SEO features that improve crawlability, indexation, topical structure, and scalable internal linking rather than piling on page-level optimization widgets.

My priority order

Google specifically emphasizes discoverability through links and has noted that large sites can encounter slower discovery when important links aren't available in their crawlable versions. Google for Developers Google for Developers

1. Build an internal-link recommendation engine

This would be my #1 product investment.

Don't make it simply:

"This article contains the phrase mortgage rates, therefore link to /mortgage-rates/."

Instead, score candidate links using several signals:

Link opportunity score =

• semantic similarity
• entity/topic overlap
• search intent compatibility
• destination page quality
• destination page organic traffic
• destination page importance/business value
• current inbound internal links
• topical relationship
• freshness
• whether the destination is already linked from the article
• anchor-text diversity
• distance between the two pages in your site graph

Then give editors something like:

Recommended links

"Mortgage rates are expected to remain elevated..."
→ Mortgage rates explained: how rates affect your payment
High confidence · 92/100

The critical distinction is recommendation rather than blindly inserting hundreds of links. Google considers excessive or manipulative linking problematic, so relevance and usefulness should drive the system. Google for Developers

2. Model your content as a graph

For a publisher, I'd maintain a first-class graph:

Article → Entity → Topic → Subtopic → Related articles

For example:

Climate change
├── Extreme heat
│   ├── Heat waves
│   ├── Urban heat
│   └── Heat deaths
├── Sea level rise
│   ├── Coastal flooding
│   └── Miami
└── Policy
    ├── Carbon tax
    └── Paris Agreement

This gives your linker much better context than raw keyword matching.

It also lets you identify:

• topics with lots of content but weak linking
• important pages with few inbound links
• clusters with no clear pillar page
• duplicate/near-duplicate articles
• articles that belong in multiple topical clusters
• newly published articles that should immediately receive links

3. Make orphan-page detection a first-class feature

I'd have a dashboard showing something like:

The interesting part is that raw link count isn't enough.

You want to identify important pages that are poorly connected.

That lets your editorial/SEO team prioritize internal-link work by expected impact rather than manually crawling thousands of URLs.

4. Automate linking in both directions

Most publishers think:

"When I publish Article A, what existing articles should A link to?"

You should also ask:

"Which existing articles should now link to newly published Article A?"

That's potentially much more valuable.

When a new article is published:

1. Extract its entities/topics.
2. Find the 20–100 most relevant existing pages.
3. Score linking opportunities.
4. Surface the top 5–10 to editors.
5. Optionally automatically add links where confidence is extremely high.
6. Re-run when the article accumulates performance data.

That creates a self-maintaining internal-link network rather than a one-time SEO project.

5. Invest heavily in crawl/indexation controls

At scale, I'd put this ahead of fancy on-page recommendations.

You want automated monitoring for:

• orphan URLs
• excessive URL depth
• pages with noindex unexpectedly
• canonical conflicts
• duplicate URLs
• soft 404s
• redirect chains
• crawl errors
• parameter/faceted URLs
• sitemap/index discrepancies
• pages receiving little/no Googlebot activity
• indexed pages with little internal connectivity

Canonicalization becomes particularly important as URL variants proliferate; Google describes canonicalization as selecting the representative URL from sets of duplicate or similar URLs. Google for Developers

6. Treat XML sitemaps as an engineering feature

For a publisher, don't have someone manually maintain one giant sitemap.

Generate them programmatically and segment them sensibly, e.g.:

/sitemap/articles-2026-09.xml
/sitemap/articles-2026-08.xml
/sitemap/authors.xml
/sitemap/categories.xml
/sitemap/videos.xml
/sitemap/images.xml

Then monitor:

submitted → discovered → indexed → ranking

That gives you a much more useful SEO health signal than simply checking whether a sitemap exists.

7. Build SEO controls into the CMS

Editors shouldn't need an SEO specialist for routine decisions.

At the CMS/template level I'd support:

• editable/automated title
• meta description
• canonical
• robots directives
• Open Graph
• Article structured data
• author/publisher information
• publication/modification dates
• breadcrumbs
• image metadata
• sitemap inclusion
• redirect management
• related-content modules
• internal-link recommendations

Structured data is worth automating where it accurately reflects the page, but I wouldn't make it your first investment. Google recommends monitoring structured-data implementations after deployment rather than treating markup as a set-and-forget feature. Google for Developers

The feature I'd build differently from most SEO platforms

I'd make "Internal Link Opportunities" the central workflow.

For every article:

Article
│
├── 7 links you should add
│   ├── High confidence
│   ├── Medium confidence
│   └── Emerging topic
│
├── 5 pages that should link TO this article
│
├── 3 related pages you're competing with
│
├── Topic cluster
│
└── Internal-link health
    ├── Inlinks: 4
    ├── Outlinks: 11
    ├── Orphan risk: Low
    └── Cluster coverage: 82%

That combines content intelligence + graph analysis + editorial workflow.

If you only have engineering capacity for 5 things

I'd build them in this order:

1. Semantic internal-link recommendation engine
2. Inbound/outbound internal-link graph + orphan detection
3. Automated crawl/indexation/canonical monitoring
4. Programmatic sitemap + indexation monitoring
5. CMS-level technical SEO automation

I'd put generic "SEO score: 78/100" tools, keyword-density checks, and similar writer-facing features substantially lower.

The strategic goal is to make your site behave like a well-connected knowledge graph, not merely a collection of individually optimized articles. That becomes increasingly valuable as your URL count grows because the problem shifts from "How do we optimize this page?" to "How do we efficiently distribute discovery and relevance across tens or hundreds of thousands of pages?" Google for Developers Google for Developers

That combines content intelligence + graph analysis + editorial workflow.

If you only have engineering capacity for 5 things

I'd build them in this order:

1. Semantic internal-link recommendation engine
2. Inbound/outbound internal-link graph + orphan detection
3. Automated crawl/indexation/canonical monitoring
4. Programmatic sitemap + indexation monitoring
5. CMS-level technical SEO automation

I'd put generic "SEO score: 78/100" tools, keyword-density checks, and similar writer-facing features substantially lower.

The feature I'd build differently from most SEO platforms

I'd make "Internal Link Opportunities" the central workflow.

1. Extract its entities/topics.
2. Find the 20–100 most relevant existing pages.
3. Score linking opportunities.
4. Surface the top 5–10 to editors.
5. Optionally automatically add links where confidence is extremely high.
6. Re-run when the article accumulates performance data.

That creates a self-maintaining internal-link network rather than a one-time SEO project.

5. Invest heavily in crawl/indexation controls

At scale, I'd put this ahead of fancy on-page recommendations.

You want automated monitoring for:

• orphan URLs
• excessive URL depth
• pages with noindex unexpectedly
• canonical conflicts
• duplicate URLs
• soft 404s
• redirect chains
• crawl errors
• parameter/faceted URLs
• sitemap/index discrepancies
• pages receiving little/no Googlebot activity
• indexed pages with little internal connectivity

Canonicalization becomes particularly important as URL variants proliferate; Google describes canonicalization as selecting the representative URL from sets of duplicate or similar URLs.

6. Treat XML sitemaps as an engineering feature

For a publisher, don't have someone manually maintain one giant sitemap.

For a mid-size publisher with a large article corpus, I’d prioritize SEO features that improve discovery, indexation, internal authority flow, and editorial efficiency—rather than piling on individual on-page optimizations.

My priority order

1. Make internal linking your flagship feature

Don't build a simple "related articles" widget.

Build a recommendation engine that understands the site's topic graph.

For every article, calculate candidate links using:

• Semantic similarity
• Shared entities/topics
• Query/keyword overlap
• Article freshness
• Historical organic traffic
• Page authority/link equity
• Destination importance
• Existing inbound/outbound links
• Whether the destination is orphaned or under-linked
• Editorial taxonomy/category relationships

Then give editors something like:

Add 3 links to this article

• "How mortgage rates affect home prices" → high relevance
• "2026 housing market forecast" → high relevance
• "What the Fed rate decision means for buyers" → medium relevance

I'd also recommend directional recommendations: don't merely ask "what should this article link to?" Ask "which pages most need links from this article?"

That's much more valuable for a publisher because you can deliberately funnel internal authority toward strategic pages.

Google explicitly treats internal links as part of how it discovers URLs, and its current documentation continues to emphasize internal-link updates as an important part of site management. Google for Developers

2. Build a topic/entity graph underneath it

This is the feature I'd invest in technically before making the recommendation UI sophisticated.

Think:

Article → entities → topics → related articles → canonical topic hubs

For example:

Article: 2026 Fed rate decision

→ Federal Reserve
→ interest rates
→ inflation
→ mortgage rates
→ Jerome Powell
→ US economy

That graph lets you recommend links based on meaning, not just matching words.

It also enables future features:

• Topic hubs
• "Missing coverage" detection
• Content clusters
• Entity pages
• Related-story modules
• Anchor-text suggestions
• Content cannibalization detection

3. Add an "orphan + underlinked" dashboard

This is one of the highest-ROI publisher features.

Don't just report:

247 orphan pages

Instead rank them by opportunity:

SEO opportunity score =
organic potential × content quality × strategic importance × link deficit

So an old article with 2,000 monthly impressions and zero internal links gets prioritized over a dead 2019 article nobody searches for.

I'd also flag:

• Pages with zero internal links
• Pages with only one inbound link
• Important pages buried 5+ clicks deep
• Articles receiving links only from low-value pages
• High-traffic pages that aren't linking to relevant strategic content

4. Treat indexation as a first-class product

At publishing scale, "we published it" ≠ "Google should index it."

You want automated controls for:

• Canonical URLs
• noindex
• Parameter/faceted URLs
• Pagination
• Tag/archive pages
• Duplicate content
• Thin pages
• Expired articles
• Author/archive pages
• Search-result pages
• Sitemap inclusion

Canonicalization is particularly important because Google can select a different canonical than the one you specify; Google's current documentation explicitly describes canonicalization as a hint rather than an absolute directive. Google for Developers Google for Developers

For a publisher, I'd build an indexation rules engine, not make editors configure this page-by-page.

5. Automate sitemaps intelligently

Don't treat the sitemap as a static XML dump of your CMS.

Generate segmented sitemaps such as:

• News/articles
• Evergreen
• Video
• Images
• Categories/topics

And monitor:

submitted → crawled → indexed → receiving impressions

That gives you an early warning system for large-scale indexation problems.

6. Build content-decay detection

This is probably the next feature I'd build after internal linking.

For each URL, detect:

• Organic clicks declining
• Impressions declining
• Rankings slipping
• Links becoming stale
• Facts becoming outdated
• New competing articles appearing
• Traffic shifting to newer URLs

Then surface:

Refresh opportunity: High

Traffic down 43% over 6 months
18% of linked references are >3 years old
4 newer articles now cover the same topic
Recommended action: consolidate/update

This is especially powerful for publishers because you already own the content inventory.

7. Put SEO controls into templates

At your scale, template SEO beats individual-page SEO.

Have configurable controls for:

• <title>
• H1
• Canonical
• Breadcrumbs
• Article schema
• Author/entity markup
• Open Graph
• Image metadata
• Internal-link modules
• Related-story modules
• Pagination
• Robots directives

One good template change can improve tens of thousands of URLs.

8. Make structured data automatic

For a publisher, I'd prioritize:

• Article / appropriate article subtype
• BreadcrumbList
• Person
• Organization
• WebSite
• Video markup where applicable

But I wouldn't make this your first major investment. Structured data can help search engines understand content, but it won't compensate for weak information architecture or poor internal linking.

The internal-linking system I'd actually build

I'd structure it as four layers:

1. Candidate generation

Find 20–50 potentially relevant destinations.

2. Ranking

Score them on:

semantic relevance + topical relationship + SEO opportunity + authority flow + freshness + editorial fit

3. Editorial filtering

Remove:

• Already-linked destinations
• Duplicates
• Poor-quality pages
• Redirects
• noindex pages
• irrelevant taxonomy pages

4. Editor UX

Show the editor the top 3–5 recommendations with suggested anchor text, rather than dumping 30 "related articles."

And crucially, let the system explain why:

Recommended: "What the Fed's next rate decision means for mortgages"
Reason: Strong topical match + destination has high search demand + currently only 2 internal links.

That explanation will dramatically improve editorial adoption.

One feature I'd avoid

Don't make AI-generated related content / links your product strategy.

AI is useful for generating candidate relationships, but the underlying system should be data-driven and deterministic enough to audit.

You don't want:

"These articles sound similar."

You want:

"These articles are semantically related, belong to the same entity cluster, have complementary search intent, and this destination has a measurable internal-link deficit."

That's a much stronger publisher SEO system.

If you have limited engineering capacity

I'd ship this sequence:

1. Internal-link recommendation engine
2. Orphan/underlinked-page detection
3. Topic/entity graph
4. Indexation + canonical controls
5. Content decay/refresh scoring
6. Sitemap/indexation monitoring
7. Template SEO automation
8. Structured data
9. AI/GEO experiments

The key strategic idea: optimize the site as a graph, not as a collection of individual articles. At mid-size publisher scale, that shift is where the compounding SEO gains are.

Google's current Search documentation also continues to emphasize scalable technical hygiene and warns against generating large volumes of substantially similar pages merely to capture search queries. Google for Developers

7. Put SEO controls into templates

At your scale, template SEO beats individual-page SEO.

Have configurable controls for:

• <title>
• H1
• Canonical
• Breadcrumbs
• Article schema
• Author/entity markup
• Open Graph
• Image metadata
• Internal-link modules
• Related-story modules
• Pagination
• Robots directives

One good template change can improve tens of thousands of URLs.

8. Make structured data automatic

For a publisher, I'd prioritize:

• Article / appropriate article subtype
• BreadcrumbList
• Person
• Organization
• WebSite
• Video markup where applicable

But I wouldn't make this your first major investment. Structured data can help search engines understand content, but it won't compensate for weak information architecture or poor internal linking.

The internal-linking system I'd actually build

I'd structure it as four layers:

1. Candidate generation

Find 20–50 potentially relevant destinations.

2. Ranking

Score them on:

semantic relevance + topical relationship + SEO opportunity + authority flow + freshness + editorial fit

3. Editorial filtering

Remove:

• Already-linked destinations
• Duplicates
• Poor-quality pages
• Redirects
• noindex pages
• irrelevant taxonomy pages

4. Editor UX

Show the editor the top 3–5 recommendations with suggested anchor text, rather than dumping 30 "related articles."

And crucially, let the system explain why:

Recommended: "What the Fed's next rate decision means for mortgages"
Reason: Strong topical match + destination has high search demand + currently only 2 internal links.

That explanation will dramatically improve editorial adoption.

One feature I'd avoid

Don't make AI-generated related content / links your product strategy.

AI is useful for generating candidate relationships, but the underlying system should be data-driven and deterministic enough to audit.

You don't want:

"These articles sound similar."

You want:

"These articles are semantically related, belong to the same entity cluster, have complementary search intent, and this destination has a measurable internal-link deficit."

That's a much stronger publisher SEO system.

If you have limited engineering capacity

I'd ship this sequence:

1. Internal-link recommendation engine
2. Orphan/underlinked-page detection
3. Topic/entity graph
4. Indexation + canonical controls
5. Content decay/refresh scoring
6. Sitemap/indexation monitoring
7. Template SEO automation
8. Structured data
9. AI/GEO experiments

The key strategic idea: optimize the site as a graph, not as a collection of individual articles. At mid-size publisher scale, that shift is where the compounding SEO gains are.

For a mid-size publisher with a large and continuously growing content library, I’d prioritize SEO features around content discovery, internal-link automation, indexation control, and editorial workflow—not a giant checklist of on-page fields.

Google explicitly says internal links help it discover pages and understand their relevance, and that every page you care about should have at least one internal link pointing to it. Google for Developers Google for Developers

My priority order

1. Build a really good internal-link recommendation engine

This would be my #1 investment.

Don't make it:

“This article mentions Taylor Swift, so link to your Taylor Swift article.”

Instead, score candidate links using multiple signals:

Candidate score = semantic relevance + topical relationship + destination value + editorial context + freshness − redundancy

For example, when an editor is publishing:

How the Fed's interest-rate decision affects mortgage rates

the system might recommend:

• your evergreen Mortgage Rates Guide
• your previous article on Fed rate decisions
• an explainer on 30-year fixed mortgages
• your relevant Federal Reserve topic hub

The system should understand that these are different kinds of relationships, not just keyword matches.

I'd expose recommendations directly in the CMS:

Suggested links

Mortgage rates guide — High confidence
Federal Reserve rate decisions — High confidence
30-year fixed mortgage — Medium confidence

And let the editor accept/reject them in one click.

Google recommends concise, relevant anchor text and contextual links, so recommendations should generate natural anchors, rather than forcing exact-match keywords. Google for Developers Google for Developers

2. Create an actual content/topic graph

For a publisher, this is more valuable than a basic “related articles” algorithm.

Model:

Article → entities → topics → subtopics → other articles → hubs

For example:

Climate change
├── Extreme heat
│   ├── Heat waves
│   ├── Urban heat islands
│   └── Heat deaths
├── Hurricanes
│   ├── Forecasting
│   └── Category system
└── Policy
    ├── Carbon tax
    └── Paris Agreement

Then recommendations can operate at several levels:

• parent topic: “What broader subject does this belong to?”
• sibling: “What else should the reader know?”
• prerequisite: “What should the reader understand first?”
• follow-up: “What would a reader logically read next?”
• evergreen reference: “Which authoritative page should this article link to?”

This also gives you the foundation for topic hubs, breadcrumbs, related-content modules and editorial analytics.

Google says it analyzes the linkages between pages to understand their relative importance, so your internal architecture should deliberately surface the pages you consider strategically important. Google for Developers

3. Make orphan detection a first-class feature

Run a graph analysis continuously and flag:

• pages with zero internal links
• pages with only one weak inbound link
• important pages buried many clicks deep
• pages receiving lots of external links but little internal support
• recently published articles that haven't acquired internal links
• high-value pages whose inbound links come primarily from irrelevant sections

I'd make this an editorial dashboard:

128 articles need internal links

🔴 23 high priority
🟡 47 medium
🟢 58 low

This is much more actionable than another generic SEO score.

4. Add destination/value scoring

Not all internal links are equally useful.

Your recommendation engine should understand that some destinations deserve disproportionate internal support.

Useful signals:

• organic traffic
• conversions/revenue
• backlinks
• search impressions
• strategic importance
• evergreen vs. ephemeral
• freshness
• current number of internal links
• topical authority
• historical performance

Then you can deliberately build:

high-value hub → supporting articles → deeper supporting content

rather than letting your internal architecture emerge accidentally from publishing chronology.

5. Automatically surface related content—but distinguish it from contextual links

I'd actually build two different systems.

Contextual links

Inside the article:

The Fed raised rates again, putting pressure on 30-year mortgage rates.

This should be highly selective and editorially relevant.

Related-content modules

At the bottom/side of the article:

More on mortgage rates

• What happens when the Fed cuts rates?
• Fixed vs. adjustable-rate mortgages
• Mortgage rates this week

The second system can be much more algorithmic.

Don't use one generic “related articles” model for both jobs.

6. Invest heavily in crawl/indexation controls

For a publisher, content volume creates an architectural problem surprisingly quickly.

I'd want automated detection of:

• duplicate URLs
• parameter URLs
• faceted archives
• thin tag pages
• pagination problems
• canonical conflicts
• redirect chains
• 404s with valuable inbound links
• orphan URLs
• indexable search-result pages
• excessive URL variants

Google specifically warns that faceted navigation can create huge numbers of URLs and consume crawling resources, potentially delaying discovery of more important content. Google for Developers Google for Developers

Likewise, pagination should expose crawlable <a href> links rather than relying solely on user-triggered JavaScript. Google for Developers

For a publisher, I'd therefore treat URL/indexation governance as a platform feature, not an SEO team's periodic audit.

7. Add “link debt” monitoring

This is a particularly useful publisher-specific feature.

Think of internal links like technical debt.

Every time you:

• publish 100 articles,
• update 50 articles,
• merge two topics,
• delete 20 URLs,
• change taxonomy,

you potentially create link debt.

Track:

New content without inbound links       17
Important pages with weak support       31
Links pointing to redirected URLs       84
Links pointing to 404s                  12
Articles missing hub link               46
Overlinked destinations                  23

Then give the editorial team a prioritized queue.

That turns SEO from a quarterly audit into an ongoing publishing workflow.

8. Don't over-prioritize AI-generated SEO copy

I'd put these relatively low:

• automatic meta descriptions
• AI title generation
• keyword-density recommendations
• “SEO score: 87/100”
• generic readability scoring
• massive lists of suggested keywords

They're useful, but they don't solve the structural problem created by hundreds/thousands of interconnected URLs.

I'd spend that engineering budget on graph quality and automation instead.

The ideal publisher SEO stack

If I were designing the roadmap, I'd make it:

P0 — Foundation

• Crawl/indexation monitoring
• Canonical/redirect validation
• XML sitemap automation
• Orphan detection
• Internal-link graph
• Contextual link recommendations
• CMS one-click link insertion

P1 — Intelligence

• Entity/topic extraction
• Semantic content graph
• Link opportunity scoring
• Destination/value scoring
• Related-content recommendations
• Topic-hub recommendations
• Content decay detection

P2 — Optimization

• Automated schema
• Title/meta suggestions
• Image SEO
• Content refresh suggestions
• SERP/content-gap analysis

P3 — Nice-to-have

• Generic SEO score
• Keyword-density scoring
• AI-generated metadata at scale

If you only build three things: I'd choose (1) contextual internal-link recommendations, (2) a content/topic graph, and (3) an automated orphan + crawl/indexation monitor.

That combination compounds: every new article becomes a potential discovery path to your existing library, while the graph tells you where those paths should go and the monitoring system catches the parts of the architecture that are being neglected. Google for Developers Google for Developers

If you're evaluating this from a product/engineering roadmap perspective, I can also lay out the actual architecture for the recommendation engine—data model, scoring algorithm, embeddings/entity layer, CMS UX, and what should run batch vs. real-time.

• Automated schema
• Title/meta suggestions
• Image SEO
• Content refresh suggestions
• SERP/content-gap analysis

P3 — Nice-to-have

• Generic SEO score
• Keyword-density scoring
• AI-generated metadata at scale

If you only build three things: I'd choose (1) contextual internal-link recommendations, (2) a content/topic graph, and (3) an automated orphan + crawl/indexation monitor.

That combination compounds: every new article becomes a potential discovery path to your existing library, while the graph tells you where those paths should go and the monitoring system catches the parts of the architecture that are being neglected.

For a mid-size publisher with lots of articles and a need to scale internal linking, I’d prioritize features that improve discovery, topical architecture, and editorial efficiency—not a giant checklist of on-page SEO fields.

My priority order

Google's current crawling guidance is particularly relevant to publishers: its advanced crawl-budget guidance is aimed at sites with 10,000+ pages that change daily and sites with large numbers of URLs that are discovered but not indexed. Google for Developers Google for Developers

1. Make internal linking a recommendation system, not a keyword tool

This would be my #1 investment.

For every article, generate something like:

Recommended links

• “Federal Reserve interest-rate decision” → /economy/fed-rates/ - Confidence: 94%
• Suggested anchor: Federal Reserve interest-rate decision
• Reason: directly related entity/topic
• “Mortgage rates” → /personal-finance/mortgage-rates/ - Confidence: 87%
• “2026 housing market outlook” → /real-estate/housing-market/ - Confidence: 81%

The important part is that recommendations should consider more than lexical similarity.

I'd score candidates using something like:

link score = topical relevance × destination value × contextual fit × freshness × link-gap opportunity

Where "destination value" could incorporate:

• organic traffic/potential
• strategic importance
• conversions/subscriptions
• backlinks/authority
• whether the page is a pillar
• whether it currently receives too few internal links

That last factor is particularly valuable. Don't just recommend the most similar article. Recommend articles that are important and under-connected.

2. Build a topic/entity graph underneath it

This is the feature that makes the recommender substantially better.

Represent:

Article → entities → topics → subtopics → related articles

For example:

2026 Fed decision

→ Federal Reserve
→ interest rates
→ inflation
→ Jerome Powell
→ mortgages
→ monetary policy

Then your system can discover useful links even when two articles don't share many exact keywords.

I'd also explicitly model parent/child relationships:

• Topic hub
• Supporting explainer
• News article
• Analysis
• Evergreen guide
• Biography/profile
• Data page

That gives you a much better internal architecture than "similar articles."

3. Add an "orphan and underlinked" dashboard

This is another high-value publisher feature.

Don't simply report:

137 orphan pages

Instead:

Then give editors one-click insertion suggestions.

I'd also identify:

• pages with zero incoming links
• pages with very few incoming links
• important pages buried several clicks deep
• topic clusters with weak connectivity
• pages receiving lots of links but having little strategic value
• pages with no links to/from their topical cluster

This turns internal linking into something measurable.

4. Make the system understand editorial intent

A publisher shouldn't have the same linking strategy for every article.

Classify content into things like:

• Breaking news
• Evergreen
• Explainer
• Analysis
• Opinion
• Guide
• Profile
• Data/statistics

Then use different rules.

For example, a breaking-news article might automatically suggest:

Context links

• What is the issue?
• Who is involved?
• Previous major developments
• Relevant explainer

An evergreen guide might instead emphasize:

Authority links

• Related guides
• Definitions
• Data
• Recent developments
• Deeper topical pages

That dramatically improves recommendation quality.

5. Automate sitemaps and canonicalization

This is less sexy, but at scale it's foundational.

Your CMS should automatically manage:

• XML sitemaps
• image/news sitemaps where appropriate
• lastmod
• canonical URLs
• redirects
• pagination/archive behavior
• noindex rules
• parameter handling
• duplicate/near-duplicate detection

Google specifically notes that canonicalization helps consolidate duplicate URLs and that canonical URLs tend to be crawled more regularly than duplicates. Google for Developers

For a publisher, I'd make "which URLs should exist in Google?" a first-class product decision rather than leaving it to individual templates.

6. Add a content-overlap detector

This is especially important if you're producing a lot of content.

Before an editor creates:

"Best mortgage rates in 2026"

show:

Potentially overlapping content

• Best mortgage rates this year — 82% overlap
• Current mortgage rates — 77%
• Mortgage rate guide — 69%

Recommendation: update existing page rather than create a new URL.

This prevents URL proliferation and keyword cannibalization.

And it pairs beautifully with internal linking: the system can tell the editor whether the right action is:

create → merge → update → redirect → link

rather than always "publish another article."

7. Build a "refresh" engine

For publishers, I'd put this surprisingly high.

Every week, surface pages where:

• rankings are declining
• traffic is declining
• information is becoming stale
• competitors have newer coverage
• the article has accumulated relevant new entities/topics
• new internal-link opportunities exist
• the page has valuable backlinks but weak current performance

Then give the editor:

Refresh opportunity

Update statistics → 3
Add section on X → 1
Add links to newer coverage → 7
Replace outdated source → 2

This is much more actionable than an SEO score of 74/100.

8. Treat metadata and schema as automated infrastructure

I'd absolutely support:

• title suggestions
• meta descriptions
• OG/social metadata
• Article schema
• Breadcrumb schema
• author information
• dates
• image metadata

But make these template + automation driven.

Don't spend your editorial team's time filling out 15 SEO fields per article.

And be careful about scaling content purely for search. Google's current spam guidance explicitly distinguishes useful publishing from scaled content abuse, where large quantities of low-value pages are generated primarily to manipulate rankings. Google for Developers

The internal-linking product I'd actually build

If you have limited engineering resources, I'd build this workflow:

1. Ingest article

↓

2. Extract entities/topics

↓

3. Retrieve ~50 candidate destinations

↓

4. Rank candidates

using:

• semantic similarity
• entity overlap
• topical hierarchy
• destination importance
• incoming-link deficit
• freshness
• editorial type
• anchor-text quality
• existing links

↓

5. Show editor top 5–10 recommendations

↓

6. Insert link with one click

↓

7. Recalculate the site's link graph

↓

8. Monitor whether important pages remain underlinked

That creates a closed-loop internal linking system, rather than a static "related articles" widget.

One important distinction

I'd separate "links that help the reader" from "links intended to pass authority."

Your recommender should optimize primarily for useful contextual navigation. Google explicitly warns against low-quality or manipulative linking practices, including keyword-rich/low-quality links and links distributed primarily to manipulate ranking. Google for Developers

So the ideal recommendation isn't:

"Here's the page with the keyword you want to rank."

It's:

"This is the most useful destination for this concept in this sentence."

Then use the graph-level metrics to make sure your strategically important content isn't systematically isolated.

If I had to pick only 5 features

For a mid-size publisher, I'd ship these first:

1. Contextual internal-link recommendations
2. Topic/entity graph
3. Orphan + underlinked-page detection
4. Content overlap / merge / refresh recommendations
5. Automated sitemap + canonical/indexation controls

I'd put generic SEO scores, keyword-density analysis, and AI title generation well below those.

The underlying principle: at publishing scale, SEO becomes an information-architecture problem more than an individual-page optimization problem.

7. Recalculate the site's link graph

↓

8. Monitor whether important pages remain underlinked

That creates a closed-loop internal linking system, rather than a static "related articles" widget.

One important distinction

I'd separate "links that help the reader" from "links intended to pass authority."

Your recommender should optimize primarily for useful contextual navigation. Google explicitly warns against low-quality or manipulative linking practices, including keyword-rich/low-quality links and links distributed primarily to manipulate ranking. Google for Developers

So the ideal recommendation isn't:

"Here's the page with the keyword you want to rank."

It's:

"This is the most useful destination for this concept in this sentence."

Then use the graph-level metrics to make sure your strategically important content isn't systematically isolated.

If I had to pick only 5 features

For a mid-size publisher, I'd ship these first:

1. Contextual internal-link recommendations
2. Topic/entity graph
3. Orphan + underlinked-page detection
4. Content overlap / merge / refresh recommendations
5. Automated sitemap + canonical/indexation controls

I'd put generic SEO scores, keyword-density analysis, and AI title generation well below those.

The underlying principle: at publishing scale, SEO becomes an information-architecture problem more than an individual-page optimization problem.

This is less sexy, but at scale it's foundational.

Your CMS should automatically manage:

• XML sitemaps
• image/news sitemaps where appropriate
• lastmod
• canonical URLs
• redirects
• pagination/archive behavior
• noindex rules
• parameter handling
• duplicate/near-duplicate detection

Google specifically notes that canonicalization helps consolidate duplicate URLs and that canonical URLs tend to be crawled more regularly than duplicates.

For a mid-size publisher with a large content library, I’d prioritize SEO features that improve discovery, reduce content decay, and make internal linking a system rather than an editorial chore. The biggest wins usually come from building a strong content graph and automation layer. DataDab Search Engine Journal

Priority 1: Internal link recommendation engine (highest ROI)

Build or buy a system that recommends links inside the publishing workflow, not as a separate SEO project.

Key capabilities:

• Semantic matching (not just keyword matching)

• Suggest links based on topic/entity similarity, search intent, and context.
• Avoid recommending links just because two pages share a word.
• Source → target prioritization

• “These 20 high-authority articles should link to these 50 underperforming articles.”
• Focus on pages with: - high impressions but low rankings
• strong backlinks but weak internal support
• revenue/subscription importance
• new content needing discovery
• Anchor text suggestions

• Recommend natural anchors.
• Detect overused exact-match anchors.
• Editorial approval workflow

• Editors accept/reject suggestions.
• Learn from decisions over time.

Internal linking is especially valuable at scale because it helps distribute existing authority, improve crawl paths, and surface deeper content. Ahrefs Andava

Priority 2: Content graph / topic cluster mapping

Treat your site as a knowledge graph:

Topic hub
   ↓
Subtopic articles
   ↓
Supporting news/features/archive content

Features to prioritize:

• Topic clustering from your existing URLs
• Entity extraction (people, places, organizations, concepts)
• Orphan content detection
• “Missing link” analysis between related stories
• Hub page identification

Example:

A publisher covering climate might discover:

• Hub: “Climate Change”
• Cluster: “Carbon Capture”
• Cluster: “EV Policy”
• Cluster: “Renewable Energy”

Then the system recommends:

• new article → hub
• older authority article → new article
• related cluster pages → each other

Priority 3: Orphan page and crawl optimization

Large publishers often have thousands of pages that technically exist but receive little internal support.

Automate reporting for:

• Pages with zero internal links
• Pages with only sitemap discovery
• Pages >3–4 clicks from important sections
• Pages losing internal links over time
• Dead-end articles

Also monitor:

• broken internal links
• redirect chains
• outdated URLs in templates

These are common large-site problems because manual review stops scaling quickly. Search Engine Journal

Priority 4: Automated “related content” modules

For publishers, this is usually a better scaling mechanism than inserting hundreds of manual links.

Examples:

• “Related stories”
• “More on this topic”
• “What happened next”
• “Background”
• “Most read in this category”
• “Deep dive”

Make the recommendation logic configurable:

Bad:

Show five random articles from the same tag.

Better:

Show articles that share entities + topic + reader intent + freshness signals.

Priority 5: Content decay monitoring

Publishers accumulate huge archives. Add systems that detect:

• traffic decline
• ranking decline
• outdated facts
• declining internal links
• old articles still attracting backlinks

Then recommend:

• refresh
• merge
• redirect
• add links from newer winners

Priority 6: Publishing workflow SEO guardrails

Prevent problems before they ship.

Useful checks at draft/publish time:

• Does this article link to a topic hub?
• Does it have internal links?
• Are there existing articles it should reference?
• Is the title competing with another URL?
• Is there a canonical conflict?
• Are structured data fields complete?

Features I would not prioritize first

For a mid-size publisher, I would usually put these behind internal linking/content architecture:

• AI-generated content briefs
• automated article rewriting
• massive keyword tracking dashboards
• generic “SEO scores”
• automatic link insertion with no editorial controls

Those can help, but they usually don’t solve the structural problems of a large archive.

A practical roadmap

First 90 days

1. Crawl entire site.
2. Build URL/content/entity inventory.
3. Find: - orphan pages
4. high-value pages lacking links
5. pages with ranking potential.
6. Launch internal link recommendations for editors.

3–6 months

1. Add topic graph.
2. Add automated related-content modules.
3. Create link equity dashboards.

6–12 months

1. Personalize recommendations by section.
2. Use ML feedback from editor approvals.
3. Automate archive refresh workflows.

If you’re a news publisher, magazine/content publisher, or publisher with programmatic pages (recipes, sports, finance, etc.), the priority stack changes a bit—especially around freshness, entities, and templates.

6–12 months

1. Personalize recommendations by section.
2. Use ML feedback from editor approvals.
3. Automate archive refresh workflows.

If you’re a news publisher, magazine/content publisher, or publisher with programmatic pages (recipes, sports, finance, etc.), the priority stack changes a bit—especially around freshness, entities, and templates.

For a mid-size publisher with a large content volume, I’d prioritize SEO features that improve discovery, crawl efficiency, topical architecture, and editorial scale—rather than adding lots of one-off on-page SEO controls.

My priority order

1. Build an internal-link recommendation engine

This would be my single highest-priority feature.

Don't make it simply:

"Find pages containing the same keyword."

Instead, score candidate links using something like:

Recommendation score = topical relevance × editorial usefulness × destination value × link opportunity × freshness

Useful inputs:

• Semantic/entity similarity between articles
• Shared topic/category/tags
• Named entities
• Search-query/topic relationships
• Existing links between the pages
• Destination page's organic traffic/impressions
• Destination page's backlinks/authority
• Whether the destination is an important evergreen page
• Recency
• Anchor-text diversity
• Number of existing internal links to the destination
• Whether the source and destination are in the same content cluster

The output to an editor should be extremely simple:

Related: How the 2026 housing market is changing
Suggested anchor: "housing market outlook"
Why: Closely related topic; this article currently has only 3 internal links.

That is much more actionable than dumping 30 "related articles" into a widget.

Google explicitly treats internal links as part of how it discovers URLs, and its large-site guidance emphasizes maintaining links to the pages you want crawled. Google Developers

2. Create a sitewide "link graph" view

For a publisher, I'd treat your content as a graph:

Article → topic → entity → related article → hub → evergreen article

Then expose SEO metrics on that graph.

You want automated reports such as:

• Orphan pages: 0–1 internal links
• Underlinked pages: important pages receiving very few links
• Overlinked pages: thousands of articles all linking to the same destination
• Dead ends: pages with few/no useful outgoing links
• Important pages buried 5+ clicks deep
• Topic clusters with weak connectivity
• New articles with no contextual links
• Old high-performing articles that should link to newer coverage

This is considerably more valuable at 500,000 URLs than manually optimizing titles.

3. Give the recommendation engine an editorial understanding

I'd strongly recommend a content/entity layer underneath the linking system.

For every article, maintain something like:

Article
├── Primary topic
├── Secondary topics
├── Entities
├── Content type
├── Publication date
├── Update date
├── Evergreen / news / seasonal
├── Geographic scope
├── Editorial section
└── Search intent

That lets you distinguish:

"Apple reports record iPhone revenue"

from

"How to buy Apple stock"

even though both contain "Apple" repeatedly.

It also lets you construct stronger hub-and-spoke architectures:

             [EVs]
            /  |  \
           /   |   \
     [Tesla] [BYD] [Rivian]
        |      |      |
     articles articles articles

Your internal linking system can then deliberately strengthen the important hub pages rather than randomly connecting semantically similar stories.

4. Put recommendations directly inside the CMS

This is an important product decision.

Don't make SEO staff visit a separate SEO dashboard to find recommendations.

While an editor is writing:

Suggested internal links

• "What the Fed's latest decision means for mortgage rates"
• "Mortgage rates explained: fixed vs. adjustable"
• "2026 housing market forecast"

Let them insert one click.

Then after publication:

SEO check: This article has 2 contextual internal links. We recommend 3 more.

That creates a continuous internal-linking workflow, rather than a quarterly SEO cleanup project.

5. Add automated orphan-page detection

I'd make this a first-class dashboard.

Something like:

Internal Linking Health

• 482,103 indexed articles
• 471,202 adequately linked
• 8,412 underlinked
• 2,489 orphaned
• 3,127 broken internal links
• 1,882 redirecting internal links

Then prioritize the problems by business/search value, not simply URL count.

For example:

Top 100 orphaned pages by organic impressions

is far more useful than:

"Here are 2,489 orphan pages."

6. Treat canonicalization and URL hygiene as infrastructure

At large volumes, this becomes disproportionately important.

Your platform should have automated handling for:

• Self-referencing canonicals
• Duplicate URL variants
• Parameter URLs
• Pagination
• Tag/category variants
• Trailing-slash consistency
• HTTP → HTTPS
• Redirect chains
• Deleted articles
• Consolidated articles
• Syndicated content

Google notes that canonicalization helps consolidate duplicate URLs and reduce unnecessary crawling of duplicates. Google Developers Google Developers

I'd also build canonical conflict detection:

Sitemap says /article-a
Canonical says /article-b
Internal links predominantly point to /article-a

That's the kind of technical inconsistency a publisher can accidentally create thousands of times.

7. Automate sitemaps around content lifecycle

Don't treat the sitemap as a manually generated list.

Generate it from your canonical content database and segment it intelligently:

/sitemap-news.xml
/sitemap-articles-001.xml
/sitemap-articles-002.xml
/sitemap-authors.xml
/sitemap-video.xml
...

Also consider tracking:

• Submitted URLs
• Indexed URLs
• Recently published URLs
• Recently updated URLs
• URLs disappearing from the sitemap
• Sitemap/indexation discrepancies

Google specifically notes that sitemaps can help discovery, particularly during large-site changes. Google Developers

8. Build a "link equity" / importance model

You don't need to reproduce Google's PageRank.

A practical internal importance score is enough.

For example:

Page importance =
  organic traffic
+ search impressions
+ backlinks
+ editorial importance
+ evergreen value
+ strategic topic value

Then use it to make recommendations.

If 20,000 articles are potentially relevant to a destination, the system should prioritize linking to the important, authoritative, canonical destination, rather than whichever page happens to share the most words.

9. Don't overinvest in AI-generated SEO content

For a publisher, I'd spend the engineering budget on AI-assisted discovery and editorial workflows, not mass generation of SEO pages.

Good uses:

• Find relevant existing articles
• Suggest internal links
• Identify missing topic coverage
• Detect cannibalization
• Cluster articles
• Extract entities
• Suggest useful anchors
• Find outdated articles
• Recommend consolidation

Less attractive:

• Automatically generating thousands of thin articles
• Automatically stuffing keywords into pages
• Producing hundreds of nearly identical location/topic pages

Google's current spam guidance explicitly warns against scaled content created primarily to manipulate search rankings, including low-value AI-generated pages. Google Developers

If I had your roadmap

I'd build it in roughly this order:

Phase 1 — highest ROI

1. Content/entity graph
2. Internal-link recommendation engine
3. Orphan/underlinked detection
4. CMS one-click link insertion
5. Broken-link + redirect monitoring

Phase 2 — scale and technical SEO

1. Automated canonical management
2. XML sitemap system
3. Duplicate/cannibalization detection
4. Internal-link graph analytics
5. Crawl/indexation monitoring

Phase 3 — optimization

1. Automated schema
2. Title/meta recommendations
3. Content freshness recommendations
4. Topic-gap analysis
5. Advanced editorial SEO scoring

The key product insight: don't build an "SEO checklist" for every article. Build an SEO control plane for the entire content graph.

For a mid-size publisher, the biggest opportunity is usually not squeezing another 2% out of individual pages—it's making sure hundreds of thousands of pages collectively form a coherent, crawlable, internally linked topical structure.

Google's current spam guidance explicitly warns against scaled content created primarily to manipulate search rankings, including low-value AI-generated pages.

If I had your roadmap

I'd build it in roughly this order:

Phase 1 — highest ROI

5. Add automated orphan-page detection

I'd make this a first-class dashboard.

Something like:

Internal Linking Health

• 482,103 indexed articles
• 471,202 adequately linked
• 8,412 underlinked
• 2,489 orphaned
• 3,127 broken internal links
• 1,882 redirecting internal links

Then prioritize the problems by business/search value, not simply URL count.

For example:

Top 100 orphaned pages by organic impressions

is far more useful than:

"Here are 2,489 orphan pages."

6. Treat canonicalization and URL hygiene as infrastructure

At large volumes, this becomes disproportionately important.

Your platform should have automated handling for:

• Self-referencing canonicals
• Duplicate URL variants
• Parameter URLs
• Pagination
• Tag/category variants
• Trailing-slash consistency
• HTTP → HTTPS
• Redirect chains
• Deleted articles
• Consolidated articles
• Syndicated content

Google notes that canonicalization helps consolidate duplicate URLs and reduce unnecessary crawling of duplicates.

I'd also build canonical conflict detection:

Sitemap says /article-a
Canonical says /article-b
Internal links predominantly point to /article-a

That's the kind of technical inconsistency a publisher can accidentally create thousands of times.

7. Automate sitemaps around content lifecycle

Don't treat the sitemap as a manually generated list.

For a mid-size publisher with a large and growing URL count, I’d prioritize SEO features that improve discovery, indexation, and contextual internal linking at scale rather than a huge checklist of on-page controls.

My priority order

1. Automated internal-link recommendations — highest priority

• Recommend relevant links while editors write, based on semantic/topic similarity, not just matching keywords.
• Suggest both source → target links and the best contextual anchor text.
• Let editors approve/reject suggestions rather than auto-publishing everything.
• Surface orphan pages, pages with very few internal links, and important pages receiving disproportionately little internal-link equity.
• Avoid generating hundreds of boilerplate links: Google explicitly warns against manipulative/low-quality linking, and descriptive anchor text is preferable. Google Developers Google Developers
• Content/entity/topic graph

• Build a graph of articles, authors, topics, entities, series, and taxonomy pages.
• Use it as the foundation for link recommendations.
• This is much more scalable than rules like "link every occurrence of keyword X to URL Y."
• Give each article a small set of primary topics + related entities, then recommend links based on those relationships.
• Large-scale crawl/indexation controls

• Detect orphan URLs.
• Find pages that are internally hard to reach.
• Monitor crawl depth.
• Identify duplicate/near-duplicate URLs.
• Flag parameter, pagination, tag, archive, and filter combinations that are creating URL bloat.
• Provide canonical/noindex controls at the template level rather than forcing editors to manage them article-by-article. Google notes that duplicate URL variants can make crawling and tracking harder. Google Developers
• Automated XML sitemaps

• Dynamic sitemap generation by content type/section.
• Separate news/video/image sitemaps where appropriate.
• Automatically remove stale/non-indexable URLs.
• Monitor submitted vs. indexed URLs.
• Internal-link health dashboard

I’d want a dashboard with:

• Orphan pages
• Pages with 0–2 internal links
• Pages with unusually high outbound internal links
• Important pages with weak internal-link coverage
• Broken internal links
• Redirecting internal links
• Links to canonicalized/non-indexable URLs
• Average click depth by content section
• Newly published pages that haven't received links
• Editorial "link opportunities" workflow

Instead of asking editors to think about SEO, give them something like:

3 recommended links for this article

"Federal Reserve interest-rate decision" → Federal Reserve rate history
"mortgage rates" → Today's mortgage-rate guide
"inflation" → What is inflation?

Include why the link is recommended, confidence, destination URL, and suggested anchor. One-click insertion is the killer UX.

7. Automated stale-content linking

• When a new high-value article is published, find older relevant articles that should link to it.
• This is particularly valuable for publishers because the archive is an enormous internal-linking asset.
• Run a daily/weekly job such as: "New page published → find 20 strongest existing linking opportunities."

The feature I'd build first

If engineering resources are limited, I'd build:

Semantic internal-link engine + orphan detection + editor approval UI.

The basic pipeline:

Article → extract topics/entities → retrieve candidate URLs → score relevance × importance × link gap → recommend anchor → editor approves

Your scoring model could incorporate:

• Semantic similarity
• Shared entities/topics
• Query/keyword relevance
• Target page organic traffic
• Target page business/editorial importance
• Whether the target is already linked from the source
• Target's current internal-link count
• Freshness
• Content type/section compatibility

That last part is important: don't optimize merely for "most similar page." You want to preferentially strengthen strategically important pages.

One feature I would not prioritize

A giant "SEO score" for every article.

For a publisher, I'd rather spend that engineering effort on automated link discovery, crawl/indexation diagnostics, canonical management, and content relationships. Those produce much more leverage when you're operating at tens or hundreds of thousands of URLs.

Google's current documentation also emphasizes that crawling/discovery becomes increasingly dependent on site size and server capacity, and specifically recommends keeping internal links updated and accessible. Google Developers

If you're evaluating this as a publisher SEO platform/product roadmap, I can also lay out a P0/P1/P2 feature roadmap with the data model and architecture I'd use for internal-link recommendations at 100k–10M URLs.

Google's current documentation also emphasizes that crawling/discovery becomes increasingly dependent on site size and server capacity, and specifically recommends keeping internal links updated and accessible.

For a mid-size publisher with a large archive, I’d prioritize SEO features that create a scalable content graph, not just individual page optimization. Internal linking becomes an architecture problem once you have thousands of URLs: you need systems that identify relationships, route authority, prevent orphan content, and keep new publishing connected to your archive. Rubab's Digital Search Engine Journal

Here’s the priority order I’d use:

Tier 1 — Must-have features

1. Semantic internal link recommendations (highest priority)

Goal: Automatically suggest the best pages to link to from each article.

Look for:

• Entity/topic similarity (not just keyword matching)
• Context-aware suggestions inside the editor
• Recommended anchor text
• Confidence scoring (“why this link?”)
• Ability to exclude bad matches

Avoid:

• “Related articles” widgets based only on recency or category
• Bulk auto-linking without editorial controls

The ideal workflow:

1. Writer drafts article.
2. SEO system identifies relevant evergreen pages.
3. Editor approves 3–8 contextual links.
4. System tracks whether the target page is gaining visibility.

Semantic matching is especially valuable because publishers often have years of related coverage that editors no longer remember exists. Yoast

2. Internal link graph analysis

You need a map of your site’s link structure.

Key reports:

• Pages with zero internal links
• Pages with too few incoming links
• Pages receiving lots of links but not ranking
• Important pages buried too deep
• Topic clusters with weak connections
• Overlinked pages wasting crawl paths

Useful metrics:

• Internal links in/out
• Crawl depth
• Organic traffic vs. internal link count
• Page importance score
• Last updated date

3. Automated orphan-page detection

Publishers accumulate orphan content constantly:

• old news stories
• seasonal guides
• migrated content
• contributor pages
• evergreen articles that fell out of navigation

Your system should flag:

• URLs with no contextual links
• URLs only reachable through sitemaps
• URLs losing internal links over time

Tier 2 — High-impact publisher features

4. Topic cluster / content hub management

Create relationships like:

Main hub:
"Climate Change"

   ↓
Supporting:
- Climate policy
- Renewable energy
- Carbon markets
- Climate science
- Company impact reports

Features:

• Define pillar pages
• Assign articles to clusters
• Find missing supporting content
• Recommend links toward hubs

Topic clustering helps search engines understand topical relationships and helps publishers avoid having dozens of competing articles targeting the same intent. Search Engine Land

5. New article → archive linking workflow

Every new article should trigger:

“Where should this point?”

and:

“Which older pages should point back to this?”

A strong system recommends:

• 2–5 evergreen resources to link from the new article
• 3–10 existing articles that should receive a link update

This is one of the biggest missed opportunities for publishers: new content often gets links, but old authoritative content does not get refreshed to support it. Ahrefs

6. Link equity / priority page modeling

Give your SEO team controls like:

“Push more internal authority toward these pages.”

Examples:

• Subscription landing pages
• Evergreen explainers
• High-value category pages
• Commercial content
• Important investigations

The system should recommend:

• “These 20 high-authority pages could support these 50 underperforming pages.”

Tier 3 — Nice-to-have at your scale

7. Anchor text optimization

Useful features:

• Detect repeated exact-match anchors
• Suggest natural variations
• Avoid linking every mention of a term to the same URL

Example:

Instead of:

“AI regulation” → same URL 800 times

Allow:

• AI policy
• artificial intelligence rules
• AI governance
• regulatory frameworks

8. Historical content refresh recommendations

Very valuable for publishers.

Example alerts:

• “This article ranks positions 8–15 and has only 3 internal links.”
• “This article has 200 backlinks but no links to your new hub.”
• “This evergreen page has not received a contextual link in 18 months.”

9. Editorial workflow integration

The best tools live where writers work.

Integrations:

• CMS editor
• Publishing checklist
• Assignment workflow
• SEO review queue

A recommendation sitting in a separate SEO dashboard often gets ignored.

Features I would deprioritize

• Automated meta description generation
• Basic keyword density checks
• Generic SEO scores
• AI-written articles
• “One-click internal linking” with no review layer

For publishers, the bottleneck is usually information architecture, not producing more text.

A practical MVP feature set

If I were building this for a mid-size publisher, I’d ship:

1. Semantic link recommendations in CMS
2. Orphan-page detector
3. Internal link graph dashboard
4. Topic hub management
5. New article linking checklist
6. Monthly “pages needing links” report
7. Human approval before publishing links

That combination would likely deliver more SEO value than dozens of smaller on-page SEO features. Editorialge Ahrefs

For a publisher specifically, I’d optimize around one question: “Does every new article strengthen the rest of the archive?” That is where internal linking becomes a compounding advantage.

A practical MVP feature set

If I were building this for a mid-size publisher, I’d ship:

1. Semantic link recommendations in CMS
2. Orphan-page detector
3. Internal link graph dashboard
4. Topic hub management
5. New article linking checklist
6. Monthly “pages needing links” report
7. Human approval before publishing links

That combination would likely deliver more SEO value than dozens of smaller on-page SEO features.

For a mid-size publisher with a large and growing article library, I’d prioritize SEO features that make your content graph stronger automatically—not features that require editors to manually optimize every URL.

Google explicitly says internal links help it discover pages and understand their relevance, and that every page you care about should be linked from at least one other page. It also uses site link structure to infer relative importance. Google for Developers Google for Developers

My priority order

1. Build an internal-link recommendation engine first

The key is contextual recommendations, not "related articles."

For every article, I'd generate something like:

Add link: “Federal Reserve interest-rate decision”
From: paragraph 4
To: /economy/fed-interest-rates
Suggested anchor: “Federal Reserve interest-rate decisions”
Confidence: 94%
Reason: Same entity + article explains the underlying concept

The engine should consider:

• semantic similarity
• shared entities
• topic/category
• search intent
• freshness
• destination's organic traffic/rankings
• destination's internal-link count
• source/destination prominence
• anchor-text diversity
• whether the destination is an evergreen authority page
• whether the destination is already linked from that article

Don't simply optimize for similarity. Otherwise you'll create a giant cluster of articles linking horizontally to each other while neglecting your most important evergreen pages.

Google recommends concise, descriptive, relevant anchor text and specifically recommends linking to relevant resources within your own content. Google for Developers

2. Make the recommendation engine authority-aware

This is the feature I'd differentiate from generic "related content" systems.

Give every URL a score based on things like:

SEO value × topical authority × business value × freshness × link deficit

Then use that to determine where links should flow.

For example:

                 Topic hub
                    ↓
          ┌─────────┴─────────┐
          ↓                   ↓
     Evergreen guide      Explainer
          ↑                   ↑
          └──── news articles ┘

A new article about mortgage rates shouldn't merely link to five other mortgage articles. It should probably link to the canonical evergreen mortgage-rate guide, while that guide links back to relevant current coverage.

This creates deliberate hub → spoke → hub architecture.

3. Orphan and underlinked detection should be automatic

Have a dashboard that identifies:

• 0 internal links in
• 1 internal link in
• important pages with surprisingly few links
• high-value pages buried many clicks deep
• pages receiving lots of links but contributing little value
• newly published pages with no contextual links
• old evergreen pages that have gradually become disconnected

This is especially valuable for publishers because content naturally decays from the site's navigation as new stories accumulate.

Google says every page you care about should have at least one internal link, and its documentation emphasizes that link structure helps Google discover content. Google for Developers

4. Build a real content/entity graph

Don't make the system fundamentally:

Article A looks like Article B → recommend B.

Instead, model:

Article
 ├── entities
 ├── topics
 ├── author
 ├── publication date
 ├── content type
 ├── search intent
 └── canonical topic

Entity
 ├── related entities
 ├── topic
 └── authority pages

Topic
 ├── hub
 ├── evergreen guides
 ├── explainers
 └── news/current coverage

That lets you make much better recommendations such as:

"This article mentions Nvidia, Blackwell, AI chips and TSMC. The strongest missing internal connection is your evergreen 'AI chip industry' guide."

rather than simply recommending another article containing the word "Nvidia."

5. Add an editorial recommendation queue, not automatic linking everywhere

I'd avoid automatically inserting 15 links into every article.

Instead:

Recommended links: 8

• 🔥 2 high-confidence/high-value
• ✓ 3 strong contextual links
• ○ 3 optional links

Let editors accept/reject individually or accept the top 2–3.

Then learn from those decisions.

Over time you can move high-confidence link classes toward automatic insertion while keeping editorial control over ambiguous ones.

6. Prioritize content hubs

For a publisher, I'd make topic hubs a first-class SEO object.

For example:

/technology/
    /artificial-intelligence/
        /ai-explainers/
        /ai-companies/
        /ai-news/
        /ai-guides/

Then automatically identify:

• missing hubs
• weak hubs
• articles that belong under a hub but aren't linked
• hubs with insufficient links to important articles
• articles that should link upward to the hub

This gives you a scalable architecture rather than relying exclusively on article-to-article links.

Google notes that logical site structure and links to important pages help search engines understand relationships between pages. Google for Developers

7. Don't neglect crawl/index management

Once you're publishing at scale, SEO isn't just about creating more links.

You need controls around:

• canonical URLs
• pagination
• tag/archive pages
• internal search
• parameter URLs
• duplicate content
• thin archives
• infinite scroll
• stale/expired content
• XML sitemaps

Google specifically notes that very large sites can encounter crawl-budget constraints and recommends using sitemaps to surface important or recently updated pages. Google for Developers

For publishers, I'd therefore build a URL inventory + indexability dashboard alongside the linking system.

What I'd actually build first

If you have a finite engineering budget, I'd do this:

Phase 1 — highest ROI

1. Content/entity extraction
2. Internal-link candidate generation
3. Recommendation scoring
4. Editor accept/reject workflow
5. Orphan/underlinked report
6. Automatic insertion after approval
7. Link graph visualization

Phase 2

1. Topic/entity hubs
2. Evergreen-vs-news classification
3. Authority-aware link distribution
4. Historical-content refresh recommendations
5. Anchor-text auditing
6. Broken-link/link-drift detection

Phase 3

1. Automated metadata/schema
2. Automated content pruning/redirect recommendations
3. Experimentation: measure whether accepted links actually improve discovery/rankings/traffic
4. ML model trained on your editors' linking decisions

The metric I'd obsess over

Don't make "number of internal links generated" the KPI.

I'd track:

% of valuable URLs with an appropriate internal link path

plus:

• orphan rate
• median internal links to priority pages
• crawl discovery time for new articles
• indexed-page rate
• organic traffic to linked destinations
• rankings/traffic for pages receiving recommendations
• editor acceptance rate
• recommendation precision

The big idea is: build a system that decides which pages deserve to be connected, not merely a system that finds pages that are similar.

For a mid-size publisher, I'd put internal-link intelligence + content graph + crawl/index management ahead of AI-generated titles/descriptions or other surface-level SEO features.

7. Don't neglect crawl/index management

Once you're publishing at scale, SEO isn't just about creating more links.

You need controls around:

For a mid-size publisher with large content volumes, I’d prioritize SEO features that improve discovery, topical relationships, and crawl efficiency before sophisticated “AI SEO” features.

Google explicitly recommends that important pages have internal links, with descriptive anchor text, and uses links both for relevance and discovering pages. Google for Developers Google for Developers

My priority order

1. Automated contextual internal-link recommendations — highest priority

• Recommend 3–10 relevant existing articles while editors write/update content.
• Rank candidates using: - semantic similarity
• shared entities/topics
• query/keyword overlap
• article freshness
• destination importance
• whether the destination already has enough internal links
• Show the exact sentence/phrase where the link could naturally fit, not just “link to these articles.”
• Give editors one-click accept/reject.

The key is to optimize for useful relationships, not simply maximize links. Google specifically recommends contextual links and concise, relevant anchor text. Google for Developers Google for Developers

2. Orphan / underlinked-page detection

Build a dashboard that identifies:

• zero internal links
• 1–2 internal links
• important pages buried several clicks deep
• high-value pages receiving disproportionately few links
• recently published articles with no links from older content

This is particularly valuable at publisher scale because manual discovery breaks down quickly. Google says every page you care about should have at least one internal link. Google for Developers

3. “Link to this page” recommendations across your archive

Don't limit recommendations to links from the article being edited. For every new article, identify existing articles that should link to it.

Example:

New article: 2026 Guide to Roth IRA Contribution Limits
Suggested inbound links:

• Roth IRA Basics
• Traditional vs. Roth IRA
• Retirement Account Contribution Limits
• How Roth IRA Income Limits Work

This solves the classic publisher problem where new content gets published but the older archive never gets updated to support it.

4. Topic/entity hubs and automatic clustering

Maintain a machine-generated content graph:

Topic → subtopic → article → related article → entity

Then use it to create/reinforce:

• topic hubs
• related-story modules
• “more on this topic” sections
• author/topic landing pages
• evergreen pillar pages

I'd favor editorially reviewable clusters over automatically generating thousands of thin taxonomy pages.

5. Internal-link health scoring

Give every URL an internal-link score based on things such as:

importance × freshness × organic traffic × external authority × topical value ÷ internal support

That lets your system answer:

“Which 500 pages should we improve next?”

That's much more useful than simply reporting “you have 4,231 orphan pages.”

6. Canonical URL enforcement in internal linking

Your recommendation engine should always prefer the canonical/primary URL rather than parameterized, duplicate, tracking, or alternate URLs.

This matters at scale because unnecessary URL variants can create substantial crawling overhead. Google specifically calls out faceted/parameter-driven URL proliferation as a source of overcrawling and slower discovery. Google for Developers

7. Crawl/indexation diagnostics

Build automated monitoring for:

• orphan URLs
• crawlable but non-indexable URLs
• canonical conflicts
• internal links to redirects
• internal links to 404s
• pages receiving links only from noindex pages
• parameter URLs being internally linked
• excessive URL duplication
• unexpectedly deep pages

For a genuinely large site, this can matter more than another on-page optimization widget. Google notes that large sites and sites generating lots of URLs need more attention to crawl efficiency. Google for Developers

Features I'd put lower on the roadmap

I wouldn't make these your first investments:

• AI-generated title suggestions
• AI meta descriptions
• generic keyword density recommendations
• automated FAQ generation
• generic “SEO score” dashboards
• automatically adding huge blocks of related links
• automatically generating thousands of topic pages

They're easier to build, but they're less differentiated and can create editorial/quality problems.

The internal-linking engine I'd actually build

The highest-value architecture would look something like:

Article published → extract topics/entities → retrieve candidate pages → score relationships → recommend links → editor approves → write links → measure outcome

Candidate scoring could roughly be:

relevance × destination value × freshness opportunity × current link deficit × topical authority

Then add negative signals:

duplicate relationship + already linked + poor destination + canonical conflict + excessive outbound links

The important product decision is to make it editor-in-the-loop, rather than blindly inserting links.

One especially valuable feature

I'd build a “Content Opportunities” queue rather than just an internal-link widget.

For example:

That turns SEO from “optimize this page” into “here are the highest-impact changes across the whole archive.”

For a mid-size publisher, I'd roughly allocate the roadmap 50% to internal-link/discovery infrastructure, 25% to crawl/indexation hygiene, 15% to topical architecture, and 10% to conventional on-page SEO tooling. The biggest moat is likely the quality of your content graph + recommendation system + editorial workflow, rather than another metadata generator.

For a mid-size publisher with lots of articles, I’d prioritize SEO features that make your content graph work automatically—not a giant checklist of on-page toggles.

Priority order

For internal linking specifically

I'd build a recommendation engine, not simply a “related stories” widget.

For every article, calculate candidate links using signals such as:

• Semantic similarity between article embeddings
• Shared entities: people, places, organizations, products, topics
• Explicit topic taxonomy
• Search/query overlap
• Existing internal-link relationships
• Article freshness
• Page importance / organic traffic
• Number and quality of existing inbound links
• Editorial section/category
• Whether the candidate is a pillar, evergreen explainer, or other strategically important page

Then score recommendations something like:

Link value = topical relevance × destination importance × contextual fit × link-gap opportunity

The link-gap opportunity piece is particularly valuable. Suppose you have:

800 articles about “NFL draft”

but only 15 internal links pointing to your strongest evergreen NFL draft guide.

Your system should recognize that as a much higher-value recommendation than simply suggesting another semantically similar article.

Google specifically recommends contextual internal links and descriptive anchor text, and says every page you care about should have at least one internal link from another page. Google for Developers

The feature I'd build first

“Add internal links” in the CMS

When an editor is writing an article, show perhaps 5–10 high-confidence recommendations, e.g.:

Recommended internal links

• “2026 NFL Draft order” → strong relevance, 94% confidence
• “How the NFL Draft works” → evergreen authority page, 91%
• “2025 NFL Draft results” → contextual historical reference, 86%

And ideally identify the exact sentence/phrase where the link belongs.

Don't automatically inject dozens of links. I'd optimize for high-confidence contextual links and let editors approve them.

Then have a second automated system operate across the existing archive.

The archive-level feature may be even more valuable

Create an Internal Linking Opportunities dashboard:

• 37 orphan articles
• 214 articles with only 1 inbound internal link
• 86 high-value pages losing internal-link opportunities
• 1,240 articles where a highly relevant destination exists but isn't linked
• 63 broken internal links
• 18 topic clusters with weak hub → spoke connections

That turns internal linking from an editorial chore into an ongoing SEO workflow.

One important architectural point

Don't use your XML sitemap as a substitute for internal architecture. Google describes sitemaps primarily as a way to help discovery, while crawlable internal links are what let Google understand and navigate the site's content. Google for Developers Google for Developers

For a publisher, I'd therefore think of the system as:

Topic graph → content graph → internal links → sitemap → crawl/index monitoring

rather than:

Publish article → generate sitemap → hope Google finds it.

Don't underestimate crawl control

Large publishers can accidentally create enormous numbers of URLs through tags, filters, search pages, parameters, archives, and other navigation mechanisms. Google specifically warns that faceted navigation can cause overcrawling and slow discovery of important new content. Google for Developers

So I'd make indexability and URL governance P0, alongside internal linking.

That includes:

• Canonical management
• noindex rules
• Robots controls
• Parameter handling
• Pagination/archive rules
• Tag/category indexing policies
• Duplicate-content detection
• Sitemap inclusion rules
• Automatic detection of unexpected indexable URL patterns

If you have limited engineering bandwidth

I'd ship these six things first:

1. Contextual internal-link recommendations
2. Orphan + underlinked-page detection
3. Topic/entity graph
4. Centralized canonical/indexability controls
5. Automated segmented sitemaps
6. Internal-link opportunity dashboard

I'd put generic AI title generators, meta-description generators, keyword-density checks, and “SEO scores” considerably lower.

For a publisher, the competitive advantage is less “did we optimize this article?” and more “does our entire archive form a coherent, crawlable, internally connected knowledge graph?”

Large publishers can accidentally create enormous numbers of URLs through tags, filters, search pages, parameters, archives, and other navigation mechanisms. Google specifically warns that faceted navigation can cause overcrawling and slow discovery of important new content.

And ideally identify the exact sentence/phrase where the link belongs.

Don't automatically inject dozens of links. I'd optimize for high-confidence contextual links and let editors approve them.

Then have a second automated system operate across the existing archive.

The archive-level feature may be even more valuable

Create an Internal Linking Opportunities dashboard:

• 37 orphan articles
• 214 articles with only 1 inbound internal link
• 86 high-value pages losing internal-link opportunities
• 1,240 articles where a highly relevant destination exists but isn't linked
• 63 broken internal links
• 18 topic clusters with weak hub → spoke connections

That turns internal linking from an editorial chore into an ongoing SEO workflow.

One important architectural point

Don't use your XML sitemap as a substitute for internal architecture. Google describes sitemaps primarily as a way to help discovery, while crawlable internal links are what let Google understand and navigate the site's content.

For a publisher, I'd therefore think of the system as:

Topic graph → content graph → internal links → sitemap → crawl/index monitoring

rather than:

For a mid-size publisher with a large archive, I’d prioritize SEO features that turn internal linking into an editorial system, not just a “related articles” widget. At scale, the biggest wins usually come from improving discovery, crawl paths, topic relationships, and the flow of authority to priority pages. Search Engine Land Ahrefs

Tier 1: Highest-impact features to build first

1. Internal link recommendation engine (contextual, not generic)

Priority: Very high

Build recommendations that understand:

• Article topic/entity similarity
• Search intent overlap
• Historical traffic/value
• Existing internal link gaps
• Publication date and freshness
• Canonical URL relationships

Good recommendations should answer:

• “What older articles should this new story link to?”
• “Which pages should link back to this important article?”
• “Which evergreen hubs should this story strengthen?”

Avoid a basic “people also read” module. For SEO, the system should prioritize contextual in-body links over random recirculation. Search Engine Land Editorialge

2. Orphan and underlinked content detection

Priority: Very high

Create dashboards for:

• Pages with zero internal links
• Pages with very few inbound links
• Important pages buried >3–4 clicks deep
• High-traffic pages that fail to distribute value
• New articles that have no supporting links

For publishers, this is often where easy wins hide: valuable content exists but is disconnected from the site graph. Ahrefs Search Engine Journal

3. Topic cluster / content graph modeling

Priority: Very high

Model content as:

Topic hub
   ↓
Evergreen guides
   ↓
News/features/updates
   ↓
Supporting articles

Features:

• Automatically group articles by topic/entity
• Identify missing hub pages
• Show weak clusters
• Recommend “connect these articles” opportunities

This helps search engines understand topical depth and helps editors know where coverage is thin. DraftRank Editorialge

Tier 2: Editorial workflow features

4. CMS publishing-time link suggestions

Priority: High

When an editor writes a story, show:

• “Link to these 5 existing articles”
• “These 3 pages need links pointing to them”
• “This article belongs in these topic hubs”

The key is putting recommendations inside the publishing workflow, not requiring a separate SEO cleanup project.

5. Priority page boosting controls

Priority: High

Let SEO editors mark:

• Revenue-driving pages
• Evergreen explainers
• Major category pages
• Strategic search landing pages

Then the system can recommend links toward those pages.

Example:

“You published 25 articles about retirement planning this month. Consider adding links from them to your retirement guide.”

6. Anchor text intelligence

Priority: Medium-high

Track:

• Overused anchors
• Missing descriptive anchors
• Exact-match overoptimization
• Inconsistent naming

Recommendations should suggest natural variations:

• “Federal Reserve interest rates”
• “Fed rate decisions”
• “How rate hikes affect mortgages”

rather than forcing the same phrase everywhere.

Tier 3: Technical SEO features worth investing in

7. Internal link graph visualization

Useful views:

• Most linked pages
• Authority sinks
• Topic islands
• Crawl dead ends
• Pages with many outbound links but little inbound support

A graph view is especially valuable for SEO teams managing tens of thousands of URLs.

8. Link health monitoring

Automate alerts for:

• Broken internal links
• Redirect chains
• Links to deleted articles
• Canonical mismatches
• Links to noindex pages

9. Freshness-aware linking

Publishers have a unique problem: old stories decay.

Useful rules:

• New articles should link to evergreen resources
• Evergreen pages should link to updated coverage
• Breaking news should eventually roll into explainers/hubs

This keeps archives valuable instead of creating disconnected content islands. Linkbot Technical SEO Library

Metrics I would put on the SEO dashboard

Don’t only measure “number of internal links added.” Track:

• % of indexed pages with at least one internal link
• Orphan page count
• Average click depth
• Internal links per priority page
• Organic traffic from internal recirculation paths
• Rankings gained after link improvements
• Crawl frequency for new content
• Topic cluster coverage

If I were sequencing the roadmap

First 90 days

1. Crawl/index/link graph audit
2. Orphan detection
3. CMS link recommendations
4. Priority page targeting

Next 6 months

5. Topic graph/entity model
6. Automated contextual suggestions
7. Anchor optimization
8. Editorial dashboards

Later

9. Predictive models (“this article is likely to become important”)
10. Automated but editor-approved link insertion

For a mid-size publisher, the sweet spot is usually AI-assisted recommendations + human editorial approval, rather than fully automated linking. You want scale without creating thousands of irrelevant links. ranktracker.com

For a mid-size publisher with lots of content, I’d prioritize SEO features that automate discovery, structure, and maintenance rather than features that help editors optimize one article at a time.

My priority order

For internal linking specifically

I'd build the recommendation engine around more than keyword similarity.

A good recommendation should consider:

• Semantic relevance — does the destination actually expand on the current passage?
• Search intent — don't link a news story to a page targeting a completely different intent just because they share words.
• Destination quality — favor indexed, canonical, useful pages with organic traffic/impressions.
• Link equity/opportunity — prioritize important pages that currently have few internal links.
• Freshness — especially useful for news publishers.
• Existing links — avoid recommending links already present.
• Section/topic boundaries — e.g. Sports → NFL pages should generally outrank unrelated Entertainment pages with similar vocabulary.
• Anchor-text diversity — recommend natural contextual anchors rather than repeatedly forcing the exact same phrase.
• Link distance — flag important pages that are several clicks deep.
• Editorial confidence — give editors a reason for each recommendation rather than presenting an unexplained score.

I'd also distinguish "add this link" recommendations from "this page should link to that page" recommendations. The former is much easier for editors to trust and operationalize.

The killer feature: an internal-link opportunity queue

Instead of giving an editor 50 suggestions, give the SEO team something like:

Priority opportunity: Article A → Article B
Why: Article B has strong search visibility but only 3 internal links; Article A contains a highly relevant contextual passage.
Suggested anchor: "2026 NFL playoff format"
Confidence: 94%

Then let the system automatically prioritize opportunities by expected SEO value × relevance × editorial confidence.

That becomes much more useful at scale than a generic "related articles" widget.

Don't neglect crawl/indexation

For a publisher producing large volumes, I'd put this almost alongside linking. Google currently describes crawl-budget optimization as particularly relevant to very large/frequently updated sites and to sites with substantial numbers of URLs in "Discovered – currently not indexed." developers.google.com

So your platform should automatically surface:

• orphan URLs
• "discovered but not indexed" patterns
• low-value parameter/faceted URLs
• duplicate/near-duplicate content
• canonical inconsistencies
• excessive pagination/archive URL generation
• redirect chains
• important pages with poor internal discovery

Google also notes that canonicalization helps reduce redundant crawling, with canonical URLs generally crawled more regularly than duplicates. developers.google.com

What I'd deprioritize

For a mid-size publisher, I wouldn't put much engineering budget into:

• generic keyword-density scoring
• automated title rewriting as the primary SEO feature
• huge "SEO score" dashboards
• AI-generated meta descriptions
• generic "related stories" based only on cosine similarity
• chasing arbitrary internal-link counts

Those can be useful, but they don't solve the scaling problem as directly.

If you can only build three things:
1. semantic internal-link recommendations → 2. orphan/underlinked-page detection → 3. automated crawl/indexation monitoring.

The key architectural decision is to build a content graph underneath all three. Once you have entities, topics, URLs, links, canonical relationships, freshness, traffic/search data, and content types represented as a graph, you can reuse that infrastructure for recommendations, audits, navigation, content hubs, and SEO reporting.

For a mid-size publisher with large content volumes, I’d prioritize SEO features that improve discovery, topical relationships, crawl efficiency, and editorial scale—rather than features that merely add metadata.

Priority order

For the internal-linking product specifically

I'd build the recommendation engine around three directions, rather than a simple "related articles" widget:

1. New → existing

"This new article should link to these 5 existing URLs."

Prioritize links that establish the new article's place in an existing topic cluster.

2. Existing → new

"These 12 existing articles are good candidates to link to this newly published URL."

This is particularly valuable because a publisher can update existing pages with established authority instead of waiting for the new article to accumulate links.

3. Existing → existing

"These 47 pages have missed internal-link opportunities."

This turns internal linking into an ongoing optimization system.

The scoring model I'd use

Don't optimize for "most semantically similar article." That's easy to build and often produces mediocre recommendations.

A better score is roughly:

Recommendation score = topical relevance × destination value × link opportunity × freshness × confidence

Where:

• Topical relevance: semantic/entity similarity
• Destination value: organic traffic, rankings, conversions, strategic importance, backlinks, etc.
• Link opportunity: does the source currently lack a link to this topic?
• Freshness: prioritize recently published/updated material where appropriate
• Confidence: how strongly does the surrounding sentence actually support the link?

You can then give editors recommendations like:

Add link: "Federal Reserve interest-rate decisions"
Target: /economy/federal-reserve-interest-rates/
Why: High topical relevance; destination is strategically important; source currently has no contextual link.

That's much more actionable than "Related articles: 8."

One important architectural choice

I'd make the system sentence/paragraph-aware, not just page-aware.

The engine should identify:

candidate passage → candidate destination → suggested anchor → confidence

That lets an editor approve the exact insertion point, while keeping control over the final copy.

Google doesn't specify a magic number of internal links per page; relevance and usefulness matter more than hitting an arbitrary quota. developers.google.com

What I would not prioritize initially

For a mid-size publisher, I'd put these behind the above:

• AI-generated meta descriptions
• automated title rewriting
• keyword-density recommendations
• generic "SEO score" dashboards
• arbitrary internal-link quotas
• automatically linking every matching keyword
• elaborate schema generators before your architecture is solid

And be especially careful with automated taxonomy/filter URLs. Large sites can generate enormous numbers of low-value crawlable URLs through faceted navigation, which can interfere with discovery of important content. developers.google.com

If you can only build 5 things

I'd ship:

1. Semantic internal-link recommendation engine
2. New ↔ existing bidirectional recommendations
3. Orphan/underlinked content report
4. Topic/entity graph + content clusters
5. Editorial one-click approve/reject workflow

That combination creates a useful content-graph optimization system, rather than another standalone SEO checklist.

If your site is, say, 10k–100k articles, I'd also design the system around incremental indexing and precomputed candidate sets from day one; you don't want every new article triggering an expensive comparison against the entire corpus.

For a mid-size publisher with a large content volume, I’d prioritize SEO features that make your site’s information architecture and internal-link graph work automatically at scale, rather than features that optimize individual articles.

Google explicitly notes that links are a major mechanism for URL discovery, and that hub/category pages can lead crawlers to new content. Google for Developers

Priority order

1. Build the recommendation engine around entities/topics, not keywords

The basic workflow should be:

Article → extract entities/topics → find candidate URLs → score candidates → recommend links → editor approves → measure outcome.

Don't make it simply:

"These two articles contain the same keywords."

For a publisher, semantic relationships are much more valuable:

• Person → career/profile/interviews
• Event → previous coverage/live updates/explainer
• Team → roster/season analysis/game coverage
• Topic → explainer/analysis/latest developments
• Location → local coverage/background
• Product/company → reviews/news/comparisons

That lets you recommend links even when the wording between two articles is substantially different.

2. Make "orphan and underlinked content" a first-class feature

I'd consider this nearly as important as generating recommendations.

Have the system identify:

• Pages with zero internal links
• Pages with very few internal links
• Important pages buried many clicks deep
• High-traffic pages with surprisingly few inbound links
• Pages ranking on page 2–3 that could benefit from relevant internal links
• Fresh articles that haven't received links from older relevant articles
• Evergreen articles whose inbound-link network has deteriorated

This is where a publisher can get substantially more value than simply adding a "Related Articles" widget.

Google's own documentation emphasizes URL discovery through links, and Search Console's Links report provides visibility into internal linking. Google for Developers Google for Developers

3. Score opportunities rather than dumping 20 recommendations on editors

An editor shouldn't see:

47 possible internal links

They should see something like:

Top opportunities

1. Link "2026 NFL salary cap explained" → "NFL salary cap rules" — High
2. Link "Chiefs offseason moves" → "Chiefs roster tracker" — High
3. Link "What is a franchise tag?" → "NFL free agency guide" — Medium

I'd make the score combine roughly:

relevance × destination importance × source importance × freshness × expected usefulness × current link deficit

Useful signals include:

• Organic traffic
• Search impressions/clicks
• Current ranking
• Page type
• Topic/entity overlap
• Recency
• Inbound internal links
• Outbound internal links
• Distance from important hub pages
• Whether the destination is already linked from the source
• Whether the destination is already heavily linked elsewhere

This prevents the classic problem where an automated system recommends hundreds of technically relevant but strategically useless links.

4. Give the system different rules for news vs. evergreen

This is particularly important for publishers.

News:

new story → previous coverage → explainer → entity/profile

Example:

Breaking story about Apple
→ previous Apple announcement
→ Apple company profile
→ explainer on the underlying technology

Evergreen:

pillar → subtopic → supporting article → related entities

Your recommendation engine should understand these relationships rather than treating every URL equally.

5. Automate the "new article → old articles" direction

This is an underrated feature.

When a new article publishes, immediately search your corpus for existing articles that should link to it.

For example:

New: "2026 World Cup host cities guide"

The system finds 80 existing articles mentioning relevant cities, teams, or tournament planning and identifies perhaps the 8 highest-value pages worth updating.

That's much more scalable than asking editors to remember to revisit older stories.

And it creates a feedback loop:

publish → identify opportunities → update old content → strengthen content cluster

6. Don't over-automate link insertion

I'd recommend automated recommendations + editorial approval before fully automatic insertion.

Especially for a publisher, bad automated linking can create:

• repetitive anchors
• awkward prose
• irrelevant associations
• excessive links
• links to outdated stories
• accidental promotion of low-quality/low-value pages

Google also recommends evaluating SEO tooling critically rather than assuming a third-party tool's recommendations are inherently correct. Google for Developers

A good UI would let an editor:

Accept | Edit anchor | Choose different destination | Dismiss | Never recommend this relationship

Those dismissals can become training data.

7. Build a "content graph" dashboard

I'd want the SEO team to be able to see:

• Topical clusters
• Hub pages
• Orphan pages
• Pages with excessive outbound links
• Pages with insufficient inbound links
• Important pages >3 clicks from a hub
• Topic clusters with weak connectivity
• New articles without contextual links
• Declining internal-link coverage over time

Think graph health, not just "number of internal links."

If resources are limited

I'd build the roadmap as:

Phase 1

1. URL/content inventory
2. Topic/entity extraction
3. Contextual link recommendations
4. Orphan/underlinked detection
5. Opportunity scoring
6. Editorial approval workflow

Phase 2

7. New-story → existing-content recommendations
8. Existing-content → new-story recommendations
9. Automated anchor suggestions
10. Broken/stale-link detection
11. Topic/hub pages

Phase 3

12. Graph visualization
13. Historical-content refresh recommendations
14. Experimentation/impact measurement
15. Selective auto-linking for very high-confidence relationships

The key architectural decision I'd make is not to build "related articles." Build a content-graph/recommendation system that happens to power internal links, related content, hubs, and editorial workflows. That gives you one underlying system instead of several disconnected SEO features.

Also, don't optimize the system around "more links." Optimize it around better discovery and stronger topical relationships. Google says its crawlers use links to discover URLs, but it does not guarantee that discovered pages will be crawled, indexed, or served. Google for Developers

developers.google.com

new story → previous coverage → explainer → entity/profile

Example:

Breaking story about Apple
→ previous Apple announcement
→ Apple company profile
→ explainer on the underlying technology

Evergreen:

pillar → subtopic → supporting article → related entities

Your recommendation engine should understand these relationships rather than treating every URL equally.

5. Automate the "new article → old articles" direction

This is an underrated feature.

When a new article publishes, immediately search your corpus for existing articles that should link to it.

For example:

New: "2026 World Cup host cities guide"

The system finds 80 existing articles mentioning relevant cities, teams, or tournament planning and identifies perhaps the 8 highest-value pages worth updating.

That's much more scalable than asking editors to remember to revisit older stories.

And it creates a feedback loop:

publish → identify opportunities → update old content → strengthen content cluster

6. Don't over-automate link insertion

I'd recommend automated recommendations + editorial approval before fully automatic insertion.

Especially for a publisher, bad automated linking can create:

• repetitive anchors
• awkward prose
• irrelevant associations
• excessive links
• links to outdated stories
• accidental promotion of low-quality/low-value pages

Google also recommends evaluating SEO tooling critically rather than assuming a third-party tool's recommendations are inherently correct.

A good UI would let an editor:

Accept | Edit anchor | Choose different destination | Dismiss | Never recommend this relationship

Those dismissals can become training data.

For a mid-size publisher with lots of content, I’d prioritize SEO features in this order. The key is to build systems that work automatically rather than asking editors to manually optimize thousands of pages.

1. Automated internal-link recommendations — highest priority

Build a recommendation engine that operates at publication and update time, suggesting perhaps 3–8 highly relevant links per article.

Prioritize recommendations based on:

• Semantic relevance — topic/entity similarity, not just matching keywords.
• Search opportunity — pages you want to strengthen that already rank positions ~5–30.
• Business/editorial importance — evergreen guides, major topic hubs, high-value sections.
• Link scarcity — pages with few internal links should get priority.
• Freshness — newly published content should quickly receive links from established pages.
• Canonical URL awareness — never recommend duplicate/redirected/noindex URLs.
• Contextual placement — recommend the specific sentence/paragraph where the link makes sense.

Google explicitly recommends contextual internal links and says every page you care about should have at least one link from another page. developers.google.com

Important: don't optimize merely for maximum number of links. Optimize for useful connections between pages.

2. Topic/entity graph

Instead of treating your site as a collection of URLs, build a lightweight graph:

Article → topics → entities → related articles → topic hub

For example:

Article: 2026 NBA draft prospects
→ NBA Draft
→ Player X
→ Team Y
→ related prospect profiles
→ NBA Draft explainer
→ Team Y draft history

This gives your recommendation engine much better candidates than simple keyword matching.

It also lets you automatically create topic clusters/hubs, which is particularly valuable for publishers with archives that grow continuously.

3. Orphan-page detection

Have the system continuously identify:

• pages with 0 internal links
• pages with only 1 weak/internal navigation link
• important pages that are several clicks deep
• newly published pages that haven't acquired links
• pages whose incoming links have disappeared after updates

Then feed those pages directly into the recommendation queue.

This is more valuable than a generic "SEO score." Google uses links both to understand relevance and to discover URLs. developers.google.com

4. Automatic "related content" modules

Give editors a configurable module such as:

Related stories

• 3–5 highly relevant articles
• 1 evergreen explainer
• 1 topic hub
• optionally 1 newer story

But don't make this purely popularity-based.

I'd use a scoring function roughly like:

recommendation score = relevance × SEO opportunity × editorial value × freshness × link scarcity

And impose diversity rules so the module doesn't return five nearly identical stories.

5. Internal-link auditing + broken-link detection

At your scale, automate detection of:

• broken internal links
• redirect chains
• links to deleted articles
• links to noncanonical URLs
• orphan pages
• excessive links to low-value pages
• pages with unusually high/low inbound-link counts

Make this an action queue, not just a report:

"127 high-value pages have no contextual links. Here are the 10 highest-priority fixes."

That's much more useful to an editorial team.

6. Automated XML sitemaps

This isn't glamorous, but it's foundational at scale.

Generate sitemaps automatically, segment them by content type/section/date where useful, and keep only canonical URLs you actually want indexed. Google currently recommends automatically generating larger sitemaps and allows splitting them into multiple files when necessary. developers.google.com

I'd also expose sitemap-level monitoring so you can see:

• submitted URLs
• indexed URLs
• newly published URLs
• stale URLs
• indexing anomalies

7. Indexation/crawl controls

For publishers, URL proliferation can become a bigger problem than the articles themselves.

Build controls around:

• tag/archive pages
• internal search
• pagination
• filters/facets
• author archives
• duplicate URL parameters
• expired content
• syndicated/near-duplicate content

You don't necessarily need sophisticated crawl-budget engineering unless you're genuinely large. Google's current guidance specifically positions crawl-budget optimization primarily for sites around 1M+ pages, or sites with 10K+ pages changing very rapidly. developers.google.com

So for a typical mid-size publisher, I'd put content architecture and internal linking ahead of elaborate crawl-budget tooling.

What I'd build first

If engineering resources are limited, my roadmap would be:

One feature I'd particularly avoid

Don't build a system whose primary output is:

"Add these 15 keywords to this article."

For a publisher, I'd spend that engineering budget on "Which existing page should this article link to, why, and exactly where?"

That creates a compounding network across the archive. And it aligns better with Google's current guidance: links should help users and Google understand related content, while the content itself should remain people-first rather than being generated primarily to capture search traffic. developers.google.com

If you tell me roughly how many URLs you have (e.g. 50K, 500K, 2M), how frequently you publish, and whether your CMS is custom/WordPress/Drupal/etc., I can sketch a concrete architecture for the internal-link recommendation system—including candidate generation, scoring, embeddings, editorial UX, and the data model.

For a mid-size publisher with lots of articles, I’d prioritize SEO features around automated discovery, internal-link quality, indexation control, and editorial workflow—not a giant checklist of on-page fields.

Google explicitly says internal links help it discover pages and understand relevance, and that every important page should be linked from somewhere else on the site. There’s also no magic number of internal links per page. developers.google.com

My priority order

For internal linking specifically

I'd build the recommendation engine around three layers:

1. Semantic relevance

For every article, generate candidate destinations based on:

• entities/topics
• embeddings/semantic similarity
• shared taxonomy
• named people/places/organizations
• related queries
• historical co-occurrence

Don't rely purely on keyword matching. A good recommendation might be:

“This article about the 2026 NBA playoffs could link to your explainer on salary-cap rules.”

even if “salary cap” barely appears in the source article.

2. SEO value

Then rank candidates by something like:

recommendation score = relevance × destination value × opportunity × confidence

Where destination value could incorporate:

• organic traffic
• impressions
• rankings
• backlinks
• business/editorial importance
• whether the destination is an evergreen pillar
• whether it is currently under-linked

This is much better than simply recommending the five most semantically similar articles.

3. Link-placement quality

The system should recommend where the link belongs, not just what to link to.

For example:

“…the changes to the 2026 voting rules…”

→ link “2026 voting rules” to the appropriate explainer.

Google recommends concise, descriptive anchor text and contextual links; it specifically cautions against generic anchors and keyword stuffing. developers.google.com

The feature I'd make especially strong

“Add these 3 links” on the publishing/edit screen.

When an editor finishes an article:

Internal linking opportunities

🟢 2026 voting rules — high confidence
Suggested placement: paragraph 4

🟢 History of the primary — high confidence
Suggested placement: paragraph 7

🟡 Candidate profile — medium confidence
Suggested placement: paragraph 11

Then one-click insert, with the editor retaining control.

That's likely to outperform a separate SEO dashboard because it puts the recommendation at the moment the editorial decision is being made.

One important architectural choice

Don't make the system optimize for “more internal links.”

Optimize for:

important pages → enough relevant links → from appropriate contextual pages

Google says there is no ideal number of links per page, while emphasizing logical site structure and linking important pages from relevant pages. developers.google.com

I'd therefore maintain an internal-link graph with metrics such as:

• orphan URLs
• inbound links per URL
• links from high-value pages
• average click depth
• pages receiving disproportionately few links
• topic clusters with weak connectivity
• articles whose only inbound links are generic navigation
• stale links
• redirected links
• over-linked destinations

That gives you a much more useful “SEO architecture health” layer than simply counting links.

If resources are limited

I'd ship these five first:

1. Internal-link recommendation engine
2. Orphan + under-linked page detection
3. One-click contextual link insertion
4. Automated sitemap/canonical/indexation management
5. Broken/redirected internal-link monitoring

Then add the semantic/entity graph and sophisticated scoring.

For a publisher, I'd put internal linking + crawl/indexation ahead of fancy AI-generated SEO metadata. Google currently identifies crawlable links, descriptive link text, and people-first content among its core SEO practices, and its current crawl-budget guidance specifically targets large, frequently updated sites. developers.google.com

If you're evaluating building vs. buying these capabilities, I can also give you a recommended SEO feature roadmap for a 10k–500k article publisher, including what belongs in the CMS versus a separate SEO service.

For a mid-size publisher with large content volumes, I’d prioritize SEO features in this order:

For the internal-link recommender specifically

I'd build it as a ranking system, not just "find articles with similar keywords."

For every candidate link, score something like:

Recommendation score = topical relevance × destination value × contextual fit × freshness × link need

Where:

• Topical relevance: semantic similarity/entity overlap.
• Destination value: organic traffic, rankings, conversions, backlinks, editorial importance, etc.
• Contextual fit: can the link be naturally inserted into this paragraph?
• Freshness: newer stories should preferentially connect to relevant established resources, while evergreen pages can accumulate links over time.
• Link need: boost orphan pages and pages with unusually few internal links.
• Diminishing returns: don't keep recommending the same destination when it already has hundreds of links.

That last piece is important. Google says the number and relationships of internal links help it understand relative importance, so you want to shape your site's link graph deliberately, rather than simply maximize the number of links. developers.google.comdevelopers.google.com

One feature I'd make unusually strong

"What should this article link to?" + "What should link to this article?"

Most editorial tools focus only on the first.

The second is arguably more valuable at scale:

This new article is important, but currently has 0–2 internal links. Here are 8 existing pages where adding a contextual link would make sense.

That turns internal linking from an editor-by-editor task into a continuous link-graph maintenance system.

Architecture I'd use

Ingestion → entity/topic extraction → candidate generation → ranking → editorial approval → automatic insertion → measurement

And keep candidate generation separate from ranking. At publisher scale, you don't want to compare every new article against your entire corpus.

A practical candidate pipeline:

1. Retrieve 50–200 candidates using embeddings/entities.
2. Filter out non-indexable, canonical-inconsistent and irrelevant pages.
3. Rank candidates using relevance + business/SEO value.
4. Select perhaps 3–10 recommendations per article.
5. Give editors the exact sentence/phrase where the link could naturally fit.
6. Learn from accept/reject/edit behavior.

I would not hard-code something like "every article gets 5 internal links." Google doesn't specify a magic number; relevance and useful contextual linking matter more. support.google.com

Don't neglect crawl efficiency

For a publisher, this is the other major scaling feature. If your CMS generates tags, filters, search pages, pagination variants, tracking parameters, etc., your internal-linking system can accidentally make the problem worse by linking to all of them.

Google specifically warns that large numbers of low-value URLs can consume crawling resources and slow discovery of valuable new content. developers.google.com

So I'd enforce a simple rule in the recommender:

Only recommend links to URLs that are canonical + indexable + strategically valuable.

If I were allocating engineering resources, my rough split would be 40% internal-link recommendation/graph, 20% content/topic understanding, 15% orphan/decay detection, 15% measurement, 10% crawl/indexation hygiene.

The highest-leverage product, in other words, isn't an SEO checklist—it’s an automated editorial link graph that continuously connects new content to your most valuable existing content while finding pages that are being neglected.

For a mid-size publisher, I’d prioritize scalable internal-linking infrastructure and indexation controls before chasing a long list of on-page SEO features.

Priority order

For the internal-link recommender specifically

I'd build the MVP around five scores:

Recommendation score = topical relevance × target importance × opportunity × freshness × confidence

Where:

• Topical relevance: semantic similarity + shared entities/topics.
• Target importance: organic traffic, backlinks, conversions, editorial priority, or your own business weighting.
• Opportunity: target currently has few relevant internal links or the source has a strong contextual opportunity.
• Freshness: prioritize newly published/updated pages when they're genuinely relevant.
• Confidence: penalize ambiguous semantic matches.

Crucially, don't optimize for maximum links. Google says there's no magical ideal number of links per page and recommends linking where it genuinely helps users. developers.google.com

A publisher-specific feature I'd strongly recommend

Build a "topic hub → supporting articles → latest coverage" model.

For example:

Climate change
→ Climate policy
→ Carbon emissions
→ Extreme weather
→ Latest climate coverage

Then your system can identify:

• articles with no link into the cluster
• important hubs with too few incoming links
• new stories that should be connected to existing evergreen coverage
• older evergreen pages that should receive links from new reporting
• competing pages that are cannibalizing the same topic

This is much more powerful than a generic "related articles" widget.

One important distinction

I'd separate reader-recommendation algorithms from SEO internal-link recommendations.

"People who read this also liked…" is optimized for engagement.

SEO recommendations should answer:

"Given this exact passage, which existing page would be genuinely useful to the reader and strategically important for our site?"

That distinction will substantially improve the quality of the system.

And don't over-index on crawl budget unless you're genuinely large. Google's current guidance says crawl-budget optimization is primarily aimed at sites around 1M+ unique URLs, or sites with 10K+ URLs that change very rapidly, among other cases. developers.google.com

If I were allocating engineering resources: I'd put roughly 40% into the content/entity graph + recommender, 25% into automated link placement and editorial UX, 20% into indexation/canonical/URL hygiene, and 15% into auditing and measurement.

The KPI I'd watch isn't "number of links added." It's incremental organic discovery/indexation + organic traffic to previously underlinked pages, while monitoring CTR and engagement to make sure recommendations remain genuinely useful.

For a mid-size publisher with large content volumes, I’d prioritize SEO features that improve content discovery, internal-link equity, crawl efficiency, and editorial consistency—not a giant checklist of on-page tweaks.

My priority order

For internal linking specifically, build this as a system

The strongest version isn't simply:

"This article mentions mortgages. Link to your mortgage article."

I'd build a recommendation engine around five signals:

1. Semantic relevance — embeddings/entities/topics.
2. Anchor opportunity — does the source article contain a natural phrase for the destination?
3. Destination value — prioritize important pages, not just the most semantically similar page.
4. Link scarcity — prioritize orphan/underlinked pages.
5. Editorial relationship — same topic cluster, series, author, geography, chronology, etc.

Then score something like:

link_score = relevance × destination_priority × link_need × anchor_quality × editorial_fit

That gives you much better recommendations than pure cosine similarity.

Google explicitly recommends contextual internal links and says every page you care about should have at least one link from another page. It also says concise, relevant anchor text helps users and Google understand the destination. developers.google.com

One feature I'd make unusually good: "link debt"

For a publisher, I'd create a dashboard showing:

• Orphan pages
• Pages with only 1–2 internal links
• High-value pages receiving too few links
• New articles with no contextual links
• Important articles buried >N clicks deep
• Pages with lots of outbound links but little inbound support
• Stale links pointing to redirects/404s
• Topic clusters with weak connectivity

Then give editors a queue:

12 high-priority linking opportunities

New article: "How the Fed's latest decision affects mortgage rates"
Recommended destination: "Mortgage rates explained"
Suggested anchor: "how mortgage rates are determined"
Confidence: 94%
Reason: Highly relevant + destination has high organic traffic + currently only 3 internal links.

That is much more useful than a generic "SEO score."

Architecture matters more than clever automation

I'd also make sure the CMS supports a hub → subtopic → article model. Google says it analyzes linkages between pages to understand relative importance, and pages with more internal links can be interpreted as more important within the site. developers.google.comdevelopers.google.com

For example:

Personal Finance
→ Mortgages
→ Refinancing
→ Mortgage rates
→ First-time buyers
→ Individual articles

Your recommendation engine should understand that hierarchy and deliberately strengthen it.

One thing I'd not over-automate

Don't automatically stuff every article with 20–30 "related stories."

At scale, that tends to produce:

• repetitive anchors
• weakly relevant links
• bloated templates
• diluted editorial signals
• unnecessary crawl paths

And if your CMS generates massive combinations of category/filter URLs, that's a separate technical SEO risk: Google warns that faceted navigation can create enormous crawl spaces and slow discovery of important content. developers.google.com

If I had a mid-size publisher's roadmap

I'd spend the first serious engineering sprint on:

1. Content graph
Articles ↔ topics ↔ entities ↔ authors ↔ sections ↔ canonical URLs.

2. Link recommendation API
Returns the best 3–10 source→destination opportunities with explanations.

3. CMS integration
Editors can accept/reject suggestions while publishing.

4. Orphan/link-debt crawler
Continuously identifies pages needing links.

5. Measurement layer
Track changes in crawl discovery, indexed pages, organic traffic, and rankings for linked destinations.

6. Automated sitemap/canonical hygiene
Especially important as the URL count grows. Google recommends using canonical URLs in sitemaps and notes this is particularly useful for large sites. developers.google.com

If you can only build three things, I'd choose (1) a content graph, (2) contextual internal-link recommendations, and (3) orphan/link-debt monitoring. Those three give you a scalable internal-linking engine rather than another collection of SEO checkboxes.