Knowledge Center Site Architecture
The Knowledge Center Site Architecture defines how every page within the Edmoss Knowledge Center is organized, connected, and maintained. It establishes the structural framework that ensures every article, guide, service page, and resource has a clear purpose, a logical location, and meaningful relationships with other content.
A well-designed architecture improves far more than navigation. It helps search engines understand topical relationships, strengthens internal linking, reduces keyword cannibalization, and enables AI-powered search systems to retrieve information with greater accuracy. By organizing content into clearly defined branches, page types, and topic clusters, Edmoss creates a scalable knowledge ecosystem that supports long-term SEO performance, E-E-A-T, and Generative Engine Optimization (GEO).
The sections below outline the architecture standards governing URL structures, page templates, internal linking, navigation, indexing, and content governance across the entire Knowledge Center.
Why This Architecture Matters
This section establishes the foundational blueprint of our documentation structure. It is designed to give technical auditors, content managers, and developers a clear view of how information hierarchy is systematically optimized for both human readability and modern search algorithms.
Governing Architecture Standards
2.1 Top-Level Branch Structure
Every pillar page lives under one of these twelve branches. Supporting articles nest one level under their pillar. No branch nests deeper than three segments from root.
Structural Rule & Hierarchy Blueprint
This URL taxonomy maintains absolute shallow depth (max 3 segments: /branch/pillar/article/) to optimize crawl budget, improve internal PageRank flow, and ensure effortless path discovery for both users and search crawlers.
| Branch | Purpose | Page Types Contained |
|---|---|---|
| /knowledge-center/ | Hub landing page — category directory, on-site search, featured guides | Hub |
| /services/ | AI, Cloud, DevOps, Mobile, Web, ERP, Cybersecurity, UI/UX, QA — one pillar per service | Service pillar, supporting article |
| /industries/ | Healthcare, Government, Fintech, Oil & Gas, Retail, Logistics, Education, Agriculture | Industry pillar, case study link-out |
| /technologies/ | Flutter, React, Node.js, Python, Kubernetes, Docker, AWS, Azure, GCP | Technology pillar, tutorial article |
| /countries/ | Nigeria, Canada, USA, UK, plus secondary markets (Australia, Germany, UAE) | Geographic pillar |
| /resources/guides/ | Long-form educational guides feeding AI Overview and LLM citation | Guide pillar, supporting article |
| /resources/case-studies/ | Client outcome stories — the primary E-E-A-T 'Experience' asset | Case study |
| /resources/whitepapers/ | Gated deeper research — lead-generation asset | Whitepaper landing |
| /resources/glossary/ | Entity definitions, interlinked from every pillar and article mention | Glossary term |
| /resources/templates-checklists/ | Downloadable practical tools — backlink and lead magnet | Tool landing |
| /compare/ | 'X vs Y' and 'Edmoss vs [competitor type]' comparison pages | Comparison pillar |
| /pricing/ | Transparent estimation ranges by service — trust plus bottom-funnel | Pricing page |
| /faq/ | Clustered FAQ hub, also feeding FAQPage schema sitewide | FAQ hub |
2.2 URL Construction Rules
Core URL Directives
Consistent, clean, and predictable URL structures maximize crawl efficiency, eliminate duplicate content risks, and clearly signal semantic hierarchy to search engines and LLM retrievers.
Lowercase, hyphen-separated: No underscores, no trailing slashes inconsistency — pick one convention sitewide and enforce it with a 301 rule.
Maximum three path segments: /branch/page-slug/ for pillars, /branch/pillar-slug/article-slug/ for supporting articles.
Keyword-focused slugs: Slug matches the primary keyword, stripped of stop words. 'AI Software Development Company' becomes /ai/ai-software-development-company, not /ai/we-are-an-ai-software-development-company-in-lagos.
No dates in URLs: Dated URLs signal staleness to both crawlers and LLM retrieval, and prevent in-place updating of evergreen pillars.
No parameters for content variation: Filtering and sorting parameters must be canonicalised to the clean URL and blocked in robots.txt where they generate infinite combinations.
Geographic URL structure: Country pages use /countries/[service]-[country], never a country subfolder duplicating the whole service tree — that creates near-duplicate content at scale.
2.3 Page Type Definitions
Six page types exist. Each has a fixed template, a fixed schema set, and a fixed position in the linking mesh. Writers must be told which type they are producing before they start.
| Page Type | Length & Purpose | Required Elements |
|---|---|---|
| Hub | 800–1,200 words. Navigational entry point to a branch. | Category grid, on-site search, 6–8 featured pillars, BreadcrumbList schema |
| Pillar | 2,000–3,500 words. Owns a broad topic end to end. | Answer-first opening, 8–12 H2s, FAQ module, named author, Related Reading module, Service or Article schema |
| Supporting Article | 900–1,600 words. Answers one narrow sub-question. | Single-question focus, up-link to parent pillar in the intro, 2–4 in-body sideways links, Article schema |
| Comparison | 1,800–2,400 words. 'X vs Y' decision content. | Comparison table above the fold, explicit decision matrix, neutral framing, Article + FAQPage schema |
| Case Study | 800–1,400 words. Proof asset for E-E-A-T. | Client context, problem, approach, named metrics, named Edmoss lead, Review/AggregateRating where a real review exists |
| Glossary Term | 150–400 words. Entity definition. | One-sentence definition first, link to the pillar that owns the entity, DefinedTerm schema |
2.4 Internal Linking Rules
Internal linking is what converts a set of pages into a topic cluster. These four rules are mandatory and should be enforced at editorial review, not left to writer discretion.
Rule 1 Up-linking
Every supporting article links up to exactly one primary pillar, in the introduction, using descriptive anchor text containing the pillar's primary keyword. One parent only — an article with two parents dilutes both clusters.
Rule 2 Down-linking
Every pillar links down to its full cluster of 8 to 15 supporting articles through a visible 'Related Reading' module placed in-body, not in the footer. Footer link dumps pass negligible contextual signal and are ignored by most retrieval systems.
Rule 3 Sideways linking
Every pillar links sideways to 2 to 4 adjacent pillars in other clusters. This cross-cluster mesh is what signals authority across the whole Knowledge Center rather than isolated silos.
Worked example — the ERP mesh:
- • ERP Software Development ↔ Inventory Management Software (shared stock data model)
- • ERP Software Development ↔ Cloud ERP vs On-Premise (deployment decision)
- • ERP Software Development ↔ ERP for Nigerian Businesses (geographic specialisation)
- • ERP Software Development ↔ Enterprise Software Development (parent category)
Rule 4 Geographic reinforcement
Country pages link to every relevant service pillar, and every service pillar links back to at least one country page. 'Software Development Company in Nigeria' should link to ERP, Inventory, Fintech and Healthcare pillars; each of those links back. This is what makes geography and service intent reinforce rather than compete.
Anchor Text Policy
Use descriptive anchors containing the target page's primary keyword or a close semantic variant.
Never use 'click here', 'read more', or bare URLs as anchors.
Vary anchor text across links to the same target — identical anchors repeated sitewide read as manipulation.
Cap in-body internal links at roughly one per 150 words to keep link equity concentrated.
2.5 Navigation and Breadcrumbs
Primary navigation: Exposes the twelve branches, never individual pillars — a mega-menu listing 300 pages destroys the hierarchy signal.
Breadcrumbs: Appear on every page below root and mirror the URL path exactly: Home › Knowledge Center › ERP › ERP for Nigerian Businesses.
Breadcrumb markup: Uses BreadcrumbList schema on every page without exception.
Hub page search: Every hub page carries an on-site search box scoped to the Knowledge Center — internal search queries become the highest-quality source of Phase 3 article ideas.
2.6 Crawl, Indexation and Canonicalisation Policy
Proper indexation controls ensure that search engines and AI crawlers spend their budget on high-value corpus pages rather than low-value archive bloat or duplicate states.
| Page Class | Index? | Notes |
|---|---|---|
| Pillars, articles, guides, comparisons | Index, follow | Core corpus. Must appear in the XML sitemap with accurate lastmod. |
| Hub and branch landing pages | Index, follow | Thin hubs must carry at least 800 words of original orienting copy or they will be treated as doorway pages. |
| Gated whitepaper landing pages | Index, follow | The landing page is indexable; the gated asset itself is not. |
| Tag and filter archives | Noindex, follow | Prevents thin-archive bloat while preserving link flow. |
| Paginated series | Index, follow | Self-referencing canonical on each page. Do not canonicalise page 2+ to page 1. |
| Search results pages | Noindex, nofollow | Blocked in robots.txt as well. |
| Author pages | Index, follow | Required for E-E-A-T. Must carry Person schema and real credentials. |
Additional Crawl Rules
Self-referencing canonical tag on every indexable page.
XML sitemaps split by branch, each under 50,000 URLs, referenced from a sitemap index and from robots.txt.
Visible 'Last updated' date on every pillar, matched to dateModified in schema — freshness is a retrieval signal for AI Overview and RAG systems.
No pillar page may be more than three clicks from the homepage.
2.7 Multi-Country Targeting
Hreflang strategy: Use hreflang only where genuinely distinct localised versions exist. Four English-language country pages targeting different markets do not need hreflang; they need distinct content, distinct primary keywords, and distinct internal link profiles.
Content uniqueness threshold: Each country page must carry at least 40% unique content relative to every other country page — local pricing, local compliance, local case studies, local office detail. Templated country pages with swapped place names are the single most common cause of geographic page cannibalisation.
Schema implementation: Nigeria pages carry LocalBusiness schema per physical office with correct geo-coordinates. Markets without a physical office carry Service schema with areaServed, never LocalBusiness.
Keyword intent segregation: Avoid targeting the same primary keyword from both a service pillar and a country page. 'Custom software development company' belongs to the service pillar; 'software development company in Nigeria' belongs to the country page.
2.8 Content Governance
Ownership & Maintenance: Every pillar has a named owner and a review date not more than six months out.
Entity Consistency: Facts about Edmoss — headcount, founding year, office locations, awards — are maintained in one source file and referenced identically everywhere on-site and on every third-party profile. Conflicting facts across sources reduce LLM citation confidence.
Publishing prerequisites: New pages are not published until their up-link, down-links and sideways links are in place. Orphaned publishing is the most common way clusters decay.
Central keyword register: Keyword register maintained centrally: no two pages may claim the same primary keyword.