Rebuilding Skene.ai’s content architecture for long-term authority

Websites as promptable authority systems

Websites are no longer primarily read by humans.

They are read, parsed, summarized, and recomposed by search systems and LLMs acting on behalf of humans. Increasingly, discovery happens through prompts, not clicks. The website is no longer the destination. It is the source of truth that other systems interrogate.

This changes the job of a website fundamentally.

A modern website must function as a promptable authority creation hub:

• A system that can be reliably queried by search engines
• A system that LLMs can ingest without contradiction
• A system that answers questions consistently, regardless of entry point

LLMs do not browse chronologically.

They do not respect navigation menus.

They do not infer intent charitably.

They extract meaning by:

• Comparing definitions across URLs
• Detecting inconsistencies in tone and scope
• Weighing which page is allowed to “own” a concept
• Penalizing ambiguity and overlap

If your site explains the same thing twice, in two different ways, you lose authority.

If your educational content leaks into commercial intent, you lose clarity.

If your product language pollutes conceptual explanations, you lose trust.

In this environment, content is no longer written “to rank.”

It is written to be correct when prompted.

That requires:

• Single-source definitions
• Explicit separation of intent
• Predictable internal structure
• Zero internal disagreement about what the product is and is not

The old Skene.ai structure was built for human navigation and keyword-based ranking.

The new structure is built for system-level consumption by search engines and LLMs. Everything that follows exists to ensure Skene.ai behaves as a coherent, interrogable system rather than a collection of pages.

This document defines a complete restructuring of Skene.ai’s content architecture.

It exists for one reason:

The previous structure was built for an earlier version of search.

Search systems have changed. User behavior has changed. AI-mediated discovery has changed.

Sites that do not realign their architecture will lose clarity, authority, and eventually rankings.

The core shift: from pages to systems

The old Skene.ai structure treated content as pages.

The new structure treats content as a system of intent layers.

Modern ranking systems, including those operated by Google, no longer evaluate pages in isolation. They evaluate:

• Intent purity
• Semantic ownership
• Structural consistency
• Internal contradictions

If two URLs answer the same question differently, both lose.

The old structure failed here.

The old structure: what existed and why it broke

Historically, Skene.ai relied on three familiar constructs:

• /plg
• /learn
• /blog

Alongside these were loosely defined pages such as:

• /product-led-growth-tools
• Overlapping solutions pages
• Mixed educational and commercial content

Why this is a problem

1. Intent mixing: Educational content, playbooks, and positioning lived on the same URLs.
2. Keyword duplication: PLG was defined on multiple pages, in multiple tones, for multiple audiences.
3. Chronological bias: Blog content decayed instead of compounding.
4. Unclear ownership: Neither users nor search systems could tell what Skene actually specialized in.

This architecture worked when ranking was keyword-centric.

It fails under intent-centric evaluation.

The new model: six layers, one job each

The rebuilt architecture is based on six non-overlapping layers.

Each layer answers exactly one type of question.

1. Pillars: conceptual authority

Question answered:

How does this system work at a conceptual level?

What changed

Old:

• /plg
• Multiple PLG explanations scattered across the site

New:

• One canonical PLG pillar
• No competing definitions anywhere else

New structure

/product-led-growth

Why this change matters

Only one URL is allowed to define a concept.

Previously, PLG was:

• Defined on /plg
• Implied on solutions pages
• Re-explained in blog posts
• Referenced inconsistently in product copy

Now:

• Pillars define concepts
• Everything else assumes them

This restores semantic authority.

Legacy paths like /plg are redirected, not preserved.

2. Resources: execution without dilution

Question answered:

How do I actually do this?

What changed

Old:

• /learn as a mixed educational hub
• /blog as a chronological feed
• Playbooks embedded inside concept pages

New:

• /resources as a pure execution layer
• No chronological feeds
• No conceptual teaching

New structure

/resources
├── /resources/guides
├── /resources/technical-deep-dives
├── /resources/playbooks
│   └── /resources/playbooks/segments
├── /resources/glossary

Chronological publishing:

• Encourages repetition
• Dilutes semantic focus
• Creates decaying URLs

Evergreen, structured resources compound instead.

Deletion is sometimes the correct SEO action.

3. Playbooks: from PLG pages to execution units

What existed before

The /plg section contained:

• Definitions
• Playbooks
• Segmented motions
• Product references

This made it unreadable to ranking systems.

What changed

All segmented PLG motions were extracted and normalized into:

/resources/playbooks/segments

Examples:

• PLG for B2B SaaS
• PLG for developer tools
• PLG for enterprise
• PLG for indie developers

Why this matters

These are not new concepts, they are constraint-based execution variants.

Keeping them under a concept page caused:

• Cannibalization
• Thin-content signals
• Repetitive definitions

Now:

• The pillar defines PLG once
• Playbooks show how it changes under constraints

4. Glossary: semantic infrastructure

Previously:

• Definitions were scattered
• Terms were inconsistently explained

Now:

/resources/glossary/*

Rules:

• One term per URL
• Factual
• No product positioning
• Linked upward to one pillar

Why this matters:

• Glossary pages are consumed directly by AI systems
• They stabilize definitions across the site
• They prevent conceptual drift inside other pages

The glossary is not optional. It is infrastructure.

Product: Mechanisms, not marketing

Question answered:

What is Skene and how does it work?

What changed

Old:

• Product explanations leaked into PLG pages
• Feature language appeared in solutions and education

New:

• Product content is isolated under /product

/product
├── /product/overview
├── /product/how-it-works
├── /product/features
├── /product/architecture
├── /product/security
├── /product/integrations
└── /product/pricing

Why this separation matters

Education builds authority.

Product pages remove friction.

When mixed, both fail.

Solutions: Problem spaces, not keywords

Question answered:

Why does this problem matter and what kind of system solves it?

What changed

Old:

• Multiple overlapping solution pages
• Category keywords treated as separate solutions
• Analytics, automation, and lifecycle blurred together

New:

A normalized solutions set:

/solutions
├── /solutions/onboarding
├── /solutions/customer-success
├── /solutions/lifecycle-automation
├── /solutions/customer-journeys
└── /solutions/retention-and-churn

Mapping old to new

• Automated Onboarding + Onboarding Tools → /solutions/onboarding
• Success Analytics → /solutions/customer-success
• Success Automation + Lifecycle Automation → /solutions/lifecycle-automation
• Customer Journey Software → /solutions/customer-journeys
• Customer Retention Software + Churn Prediction Software → /solutions/retention-and-churn

Why consolidation wins

Search systems prefer:

• One page that fully owns a problem
• Over many pages that partially overlap

This eliminates internal competition.

Alternatives: Explicitly commercial

Question answered:

How does this compare and when should I choose it?

What changed

Pages like:

• /product-led-growth-tools

were pretending to be educational while acting as comparison pages.

They were moved to:

/alternatives

Examples:

/alternatives/product-led-growth-tools
/alternatives/skene-vs-pendo
/alternatives/skene-vs-amplitude

Why this matters

Comparison intent is commercial intent.

Keeping it out of pillars and resources:

• Protects authority
• Prevents E-E-A-T dilution
• Clarifies buyer journeys

Community: Proof of life, not SEO

Question answered:

Is this real and alive?

What changed

Community was previously implicit or missing.

Now it is explicit and isolated:

/community
├── /community/open-source
├── /community/experiments
├── /community/discussions
├── /community/events
├── /community/contribute

Community pages:

• Link outward
• Do not compete for rankings
• Reinforce trust indirectly

9. Homepage: From explainer to router

Previously:

• Homepage tried to explain PLG
• Overloaded first-time visitors

Now:

• Homepage routes users into the correct layer

It answers:

1. What category is this?
2. Who is this for or not for?
3. Where should I go next?

Teaching happens elsewhere.

Internal linking law

The old site linked freely.

The new site links with discipline.

• Pillars → Resources
• Resources → Pillars and glossary
• Solutions → Product and playbooks
• Product → Use cases
• Alternatives → Product and pricing
• Community → External

No leakage.

Why this architecture works long term

• It scales without duplication
• It survives algorithm shifts
• It makes wrong content harder to publish
• It forces clarity at the sentence level

Most sites fail because they optimize content.

This structure optimizes decisions.

Final principle

If a page does more than one job, it is wrong.

This architecture ensures every page has exactly one reason to exist.