Why This Chapter Matters

A website is never truly finished.

New knowledge is added.

Old knowledge becomes outdated.

Visitor interests change.

Search behaviour evolves.

Technologies change.

New devices emerge.

Links break.

Documents are replaced.

Interactive tools receive unexpected responses.

Some pages become highly valuable.

Others remain invisible.

An organisation may launch a website with careful planning and strong content. Yet without regular measurement, it cannot know whether the system is actually helping people discover, understand and use its knowledge.

The website may look impressive while important resources receive no visitors.

A detailed article may attract attention but fail to guide readers towards the next useful page.

A calculator may be opened frequently but rarely completed.

A document may be downloaded hundreds of times without anyone knowing whether visitors found it through search, an article or a social-media post.

A frequently asked question may receive repeated searches even though the answer already exists somewhere on the website.

A broken internal link may remain unnoticed for months.

Analytics helps reveal these realities.

However, measurement should not be reduced to one large number displayed on a dashboard.

Total Visitors.

Page Views.

Sessions.

Downloads.

These numbers can be useful, but they do not automatically explain whether the website is achieving its purpose.

Suppose a technical manual receives only 300 visitors in one year.

That may appear small.

But what if those visitors include:

• 40 food-processing entrepreneurs, 

• 12 university teachers, 

• 8 government officers, 

• and 3 organisations that adopt the framework? 

The manual may create significant impact despite modest traffic.

Now consider a humorous article that receives 50,000 visits but leads to no further reading, no downloads and no meaningful engagement.

The larger number does not necessarily represent greater organisational value.

Measurement must therefore begin with purpose.

Different pages have different objectives.

An article may aim to explain.

A case study may aim to establish evidence.

An FAQ may aim to answer quickly.

A calculator may aim to help a visitor estimate.

A document page may aim to encourage a useful download.

An internship page may aim to generate suitable applications.

An author profile may aim to establish knowledge authority.

Each should be measured according to what it is meant to accomplish.

Analytics also helps the organisation listen.

Internal search queries reveal what visitors are unable to locate.

Unanswered questions reveal missing knowledge.

Repeated exits may reveal confusing content.

Abandoned forms may reveal excessive demands.

Downloads may indicate practical interest.

Search-engine queries may reveal how people describe their problems.

AI citations may reveal which parts of the organisation’s knowledge are being recognised, misunderstood or ignored.

This makes analytics more than a technical reporting function.

It becomes a learning system.

The purpose is not merely to measure visitors.

It is to understand:

• what people are seeking, 

• what they discover, 

• what they use, 

• where they struggle, 

• what they ignore, 

• and what the organisation should improve next. 

The programmer’s responsibility is therefore not limited to installing an analytics script.

The programmer must build a measurement system that is:

• purposeful, 

• privacy-conscious, 

• technically reliable, 

• connected with content decisions, 

• and understandable to the people responsible for improving the website. 

A well-designed Knowledge Visibility Ecosystem does not merely publish knowledge.

It observes how that knowledge is discovered and used.

It then improves itself continuously.

________________________________________ 

Rule 15.1; Define Success Before Measuring It

The Rule

Every major page, tool and knowledge section should have a clearly defined purpose before performance is measured.

Why This Rule Exists

Numbers have meaning only when compared with an objective.

Suppose a webpage receives 2,000 visits.

Is that good?

The answer depends upon what the page was meant to achieve.

If it is a national public-awareness article, 2,000 visits may be modest.

If it is a specialised technical guide intended for 100 professionals, 2,000 visits may be exceptional.

Similarly, a high time-on-page may mean that visitors are deeply engaged.

It may also mean they are struggling to find the answer.

A short visit may indicate disinterest.

Or it may mean the visitor found the answer immediately.

Measurement must therefore begin with questions such as:

What should the visitor understand?

What action should the visitor be able to take?

What should happen after reading?

What organisational purpose does this page serve?

For example:

FAQ Page Purpose

Help visitors obtain a direct answer and reach detailed guidance where necessary.

Calculator Purpose

Help food entrepreneurs estimate production cost and understand major cost drivers.

Case Study Purpose

Demonstrate how a particular intervention worked in a real situation.

Document Page Purpose

Help visitors understand and download the correct version of a knowledge resource.

Each purpose suggests different measurements.

What Most Programmers Do

Analytics is added globally.

The same metrics are applied to every page.

Success is judged primarily by traffic.

Better Practice

Define one or more meaningful outcomes for each important content type.

Examples include:

• answer viewed, 

• related article opened, 

• document downloaded, 

• calculator completed, 

• application submitted, 

• case study explored, 

• return visit, 

• or outdated-content report submitted. 

Do not create dozens of targets.

Choose the few that genuinely reflect purpose.

Programming Impact

This requires:

• content objectives, 

• event definitions, 

• conversion mapping, 

• page-type analytics, 

• and alignment between CMS records and measurement systems. 

________________________________________ 

Rule 15.2; Track Which Pages Visitors Actually Use

The Rule

Measure traffic at the individual-page and content-type level rather than looking only at website-wide totals.

Why This Rule Exists

Overall traffic hides important differences.

A website may receive 100,000 visits while 90 per cent of those visits go to five pages.

Hundreds of valuable knowledge pages may receive almost no attention.

Page-level measurement helps the organisation identify:

• most visited pages, 

• most visited subjects, 

• entry pages, 

• frequently revisited resources, 

• seasonal content, 

• and pages that attract unexpected audiences. 

The purpose is not simply to celebrate popular pages.

Popular pages can also be used as gateways towards deeper knowledge.

If a widely read article introduces food costing, it should connect visitors with:

• the complete framework, 

• a calculator, 

• worked examples, 

• and downloadable templates. 

Analytics can reveal whether visitors follow those pathways.

What Most Programmers Do

The dashboard displays total visitors and total page views.

No one examines individual knowledge sections.

Better Practice

Review performance by:

• page, 

• subject, 

• author, 

• content type, 

• language, 

• audience, 

• project, 

• and publication period. 

A document library should be assessed differently from a news section.

An author profile should be assessed differently from a calculator.

Programming Impact

This requires:

• stable page identifiers, 

• content-type dimensions, 

• CMS-to-analytics integration, 

• and filters that survive URL changes. 

________________________________________ 

Rule 15.3; Track Where Visitors Enter and Where They Leave

The Rule

Understand which pages begin visitor journeys and where those journeys commonly end.

Why This Rule Exists

Visitors rarely arrive through the homepage alone.

They may enter through:

• a search result, 

• a shared article, 

• a document page, 

• a case study, 

• an FAQ, 

• or a link from another website. 

The entry page creates the visitor’s first impression of the organisation.

It should provide:

• clear context, 

• visible identity, 

• meaningful navigation, 

• and relevant next steps. 

Exit behaviour can also reveal useful patterns.

A visitor may leave because:

• the question was answered, 

• the content was irrelevant, 

• the next step was unclear, 

• the page was slow, 

• a link was broken, 

• or the visitor moved to an external source. 

Not every exit is a failure.

A visitor leaving after opening an official government notification may have completed the intended journey.

The organisation must interpret exits in context.

What Most Programmers Do

A high exit rate is automatically treated as bad.

No distinction is made between successful completion and visitor frustration.

Better Practice

Review:

• entry page, 

• pages visited afterwards, 

• action completed, 

• exit page, 

• and likely visitor purpose. 

For important pages, ask:

Was there a clear next step?

Did the page answer the question?

Did the visitor reach the intended resource?

Programming Impact

This requires:

• journey analysis, 

• event tracking, 

• referral information, 

• exit-path reporting, 

• and meaningful page-group definitions. 

________________________________________ 

Rule 15.4; Measure Internal Search Behaviour

The Rule

Record what visitors search for inside the website and whether those searches produce useful results.

Why This Rule Exists

Internal search is one of the most valuable sources of organisational intelligence.

Visitors often describe their needs in their own words.

They may search for:

• ginger powder costing, 

• rooftop garden summer, 

• internship appointment letter, 

• pesticide residue in spices, 

• or red rice pasta. 

These phrases reveal:

• visitor language, 

• unmet needs, 

• content gaps, 

• confusing terminology, 

• and emerging areas of interest. 

Search behaviour can also reveal architectural problems.

If hundreds of visitors search for a page that should be easy to reach through navigation, the website may not be organised clearly.

A search with no results is especially valuable.

It tells the organisation:

Someone expected this knowledge to exist.

What Most Programmers Do

Internal search is treated as a convenience feature.

Search terms are not recorded or reviewed.

Better Practice

Track:

• search phrase, 

• number of results, 

• result selected, 

• repeated search, 

• search refinement, 

• and zero-result searches. 

Review common spelling variations and regional terminology.

For example, visitors may search for both:

• vermicompost, 

• vermi compost, 

• earthworm compost, 

• and kechua khad. 

The system should learn from actual usage.

Programming Impact

This requires:

• privacy-conscious search logging, 

• zero-result reporting, 

• synonym management, 

• query refinement tracking, 

• and integration with content planning. 

________________________________________ 

Rule 15.5; Track Downloads as Knowledge Use, Not Merely Clicks

The Rule

Measure document downloads while preserving enough context to understand what was downloaded and why.

Why This Rule Exists

A download often represents stronger practical interest than a page view.

A visitor may download:

• a manual, 

• costing spreadsheet, 

• checklist, 

• internship form, 

• case-study report, 

• or training presentation. 

However, a download count alone remains incomplete.

The organisation should understand:

• which document was downloaded, 

• which version, 

• from which page, 

• in which language, 

• and whether the visitor viewed the summary first. 

A document downloaded 500 times from a relevant technical article may indicate genuine knowledge use.

A file repeatedly downloaded by automated bots may not.

What Most Programmers Do

All download buttons are tracked as one generic event.

The document identity is missing.

Better Practice

Record:

• document identifier, 

• document title, 

• version, 

• language, 

• format, 

• source page, 

• and date. 

Where several formats exist, distinguish:

• PDF, 

• Word, 

• Excel, 

• and presentation downloads. 

Do not require personal identification merely to count a download.

Programming Impact

This requires:

• file-level event tracking, 

• stable document IDs, 

• version metadata, 

• bot filtering, 

• and reporting by document type. 

________________________________________ 

Rule 15.6; Measure Interactive Tool Completion and Abandonment

The Rule

Track whether visitors start, continue and complete quizzes, calculators, surveys and self-assessment tools.

Why This Rule Exists

A tool may receive many visits but produce few completed results.

This may indicate:

• too many questions, 

• unclear purpose, 

• poor mobile design, 

• confusing language, 

• unnecessary registration, 

• technical errors, 

• or questions visitors cannot answer. 

The point of abandonment is particularly useful.

If many visitors leave at the question requesting a phone number, the problem may not be the tool itself.

If they leave when asked for detailed financial information, the organisation may be asking too much too early.

If they leave on mobile devices but complete the tool on desktop, usability may be the issue.

What Most Programmers Do

Only completed submissions are recorded.

The organisation never knows how many visitors attempted the tool.

Better Practice

Track:

• tool opened, 

• tool started, 

• major stage completed, 

• tool abandoned, 

• result generated, 

• result downloaded, 

• and related content opened. 

Do not record sensitive answer values unless they are genuinely required.

Aggregate behaviour may be sufficient for improvement.

Programming Impact

This requires:

• stage events, 

• anonymous session tracking, 

• abandonment analysis, 

• mobile segmentation, 

• and privacy-aware response handling. 

________________________________________ 

Rule 15.7; Identify Important Pages Receiving Little or No Traffic

The Rule

Regularly identify valuable pages that remain undiscovered or underused.

Why This Rule Exists

Low traffic does not automatically mean poor content.

A page may receive little attention because:

• no other pages link to it, 

• its title is unclear, 

• it is missing from the sitemap, 

• search engines cannot access it, 

• it is buried inside a document library, 

• the terminology does not match visitor language, 

• or the subject has a naturally small audience. 

Such pages should be reviewed rather than immediately deleted.

A specialised technical guide may deserve preservation even when its audience is limited.

The correct question is not:

Why is this page unpopular?

It is:

Is this page reaching the people for whom it was created?

What Most Programmers Do

Low-traffic pages are ignored.

Or they are deleted solely because traffic numbers appear small.

Better Practice

Classify low-traffic pages.

Possible categories include:

Hidden but Valuable

Improve internal links and discovery.

Too Specialised

Preserve for the appropriate audience.

Outdated

Update or archive.

Duplicated

Consolidate.

Poorly Titled

Improve page identity.

Technically Blocked

Correct indexing or rendering problems.

Programming Impact

This requires:

• low-traffic reports, 

• importance classifications, 

• orphan-page detection, 

• sitemap checks, 

• and editorial review workflows. 

________________________________________ 

Rule 15.8; Monitor Broken Links and Failed Resources

The Rule

Continuously identify broken internal links, failed downloads, missing images and unavailable external references.

Why This Rule Exists

Websites deteriorate gradually.

Documents are renamed.

Projects are reorganised.

External websites change.

Staff members delete files.

Images are moved.

Old URLs stop working.

A single broken link may appear minor.

Hundreds of broken links make the knowledge ecosystem unreliable.

Broken resources also interrupt visitor journeys.

A case study may refer to a technical guide that no longer exists.

A document page may offer a file that returns an error.

A cited government report may have moved.

These failures reduce trust and make the organisation appear careless.

What Most Programmers Do

Broken links are repaired only when a visitor complains.

Better Practice

Monitor:

• internal links, 

• external links, 

• file downloads, 

• images, 

• embedded media, 

• redirects, 

• and API resources. 

Distinguish between:

• temporary failures, 

• permanent removal, 

• redirects, 

• and access restrictions. 

Record which pages contain the broken reference so editors can repair it efficiently.

Programming Impact

This requires:

• scheduled link checking, 

• HTTP status monitoring, 

• failed-download logging, 

• redirect-chain detection, 

• and administrative alerts. 

________________________________________ 

Rule 15.9; Monitor Public Search Queries and Discovery Patterns

The Rule

Review the words and questions through which visitors discover the website from external search systems.

Why This Rule Exists

Search queries reveal how people describe their needs.

The organisation may use professional terminology.

Visitors may use everyday language.

For example, an expert may write:

Post-harvest moisture management in dehydrated spices.

A visitor may search:

Why does ginger powder become lumpy?

Both may refer to related knowledge.

Search-query analysis helps the organisation identify:

• popular questions, 

• unexpected interpretations, 

• emerging concerns, 

• geographical differences, 

• and language gaps. 

It may also reveal that a page is attracting the wrong audience.

A technical page may receive visitors searching for a completely different meaning of the same word.

What Most Programmers Do

Search impressions and clicks are viewed only as traffic numbers.

The language of the queries is not studied.

Better Practice

Review:

• search queries, 

• pages shown, 

• pages selected, 

• position changes, 

• language, 

• device, 

• country or region where appropriate, 

• and queries receiving impressions but few clicks. 

Do not rewrite pages mechanically around every search phrase.

Use query data to understand visitor intent and improve clarity.

Programming Impact

This requires:

• search-performance integration, 

• query-to-page reporting, 

• language analysis, 

• privacy-conscious geographic grouping, 

• and long-term trend comparison. 

________________________________________ 

Rule 15.10; Review How AI Systems Represent and Cite the Organisation

The Rule

Periodically examine whether AI systems discover, summarise and cite the organisation’s knowledge accurately.

Why This Rule Exists

AI systems are becoming another path through which people encounter organisational knowledge.

A visitor may never open the website directly.

They may ask an AI assistant:

• How is food-product cost calculated? 

• Can red rice be used to make pasta? 

• What are the hidden costs of cheap spices? 

• How should a rooftop garden prepare for summer? 

The AI system may:

• cite the organisation, 

• summarise its content without citation, 

• misunderstand the page, 

• use outdated information, 

• or overlook it completely. 

AI visibility is difficult to measure perfectly.

Different systems behave differently.

Answers may vary by user, time, location and prompt.

The organisation should therefore avoid treating AI citation as one exact numerical metric.

The purpose is to observe patterns.

What Most Programmers Do

Either AI visibility is ignored completely or exaggerated claims are made based upon a few examples.

Better Practice

Periodically test representative questions related to the organisation’s core knowledge.

Record:

• whether the website is cited, 

• which page is cited, 

• whether the summary is accurate, 

• whether outdated information appears, 

• and which competing sources are used. 

Where misunderstandings occur, examine the underlying page.

The solution may involve:

• clearer answers, 

• stronger author identity, 

• better dates, 

• improved structured data, 

• better internal linking, 

• or more explicit evidence. 

Do not attempt to manipulate AI responses through hidden claims.

Improve the clarity and authority of the source knowledge.

Programming Impact

This requires:

• a documented AI-query test set, 

• citation observations, 

• page-level records, 

• periodic manual review, 

• and integration with content-improvement workflows. 

________________________________________ 

Rule 15.11; Maintain a Formal Content Review and Update Calendar

The Rule

Every important knowledge asset should have an assigned review schedule based on how quickly its information may change.

Why This Rule Exists

Not all content ages at the same rate.

A historical article may remain relevant for decades.

A government-scheme page may change within months.

A price comparison may become outdated in weeks.

A software guide may require frequent revision.

A legal or regulatory note may need immediate review after a notification.

Without a calendar, updates depend upon memory.

Important knowledge gradually becomes stale.

A review date does not mean the page must be rewritten.

It means someone should examine whether it remains:

• accurate, 

• complete, 

• current, 

• accessible, 

• and properly connected. 

What Most Programmers Do

The CMS stores a publication date and perhaps a last-updated date.

No future review date exists.

Better Practice

Assign review frequency according to content type.s

For example:

The exact schedule should reflect organisational risk and capacity.

Programming Impact

This requires:

• next-review dates, 

• content owners, 

• reminder systems, 

• review status, 

• escalation, 

• and reporting for overdue content. 

________________________________________ 

Rule 15.12; Compare Performance Before and After Major Changes

The Rule

Evaluate whether redesigns, rewrites and technical improvements actually improve the visitor experience.

Why This Rule Exists

Organisations frequently make changes based on assumptions.

A page title is rewritten.

Navigation is reorganised.

A long article is shortened.

A calculator is redesigned.

A registration requirement is removed.

A new related-reading section is added.

Without comparison, nobody knows whether the change helped.

A visually attractive redesign may reduce readability.

A shorter form may increase completion.

A new heading may attract a more appropriate audience.

A performance improvement may reduce mobile abandonment.

Measurement should therefore be part of the change process.

What Most Programmers Do

The new version replaces the old one.

Earlier performance is not recorded.

Success is judged by personal preference.

Better Practice

Before a major change, record relevant baseline measures.

After the change, compare an appropriate period.

Possible measures include:

• page entry rate, 

• completion rate, 

• internal-link use, 

• download rate, 

• mobile abandonment, 

• search visibility, 

• and support questions received. 

Allow enough time for meaningful comparison.

Do not declare success after one unusual day.

Programming Impact

This requires:

• release dates, 

• baseline snapshots, 

• version-aware analytics, 

• controlled experiments where appropriate, 

• and change annotations in reports. 

________________________________________ 

Rule 15.13; Do Not Judge Success Only by Total Visitor Numbers

The Rule

Evaluate quality, relevance, usefulness and organisational impact alongside traffic.

Why This Rule Exists

Large numbers are attractive.

They are easy to display.

They are also easy to misunderstand.

A website may increase traffic through sensational titles while weakening its knowledge purpose.

Another may serve a smaller but highly relevant professional audience.

For an organisation’s Knowledge Visibility Ecosystem, meaningful indicators may include:

• correct audience reached, 

• useful documents downloaded, 

• tools completed, 

• repeat use, 

• applications received, 

• questions answered, 

• external references earned, 

• adoption of frameworks, 

• professional enquiries, 

• and improvements in visitor understanding. 

A specialised page read by fifty decision-makers may be more valuable than a general page read by ten thousand casual visitors.

What Most Programmers Do

The dashboard highlights:

• users, 

• sessions, 

• page views, 

• and traffic growth. 

Everything else receives little attention.

Better Practice

Use a balanced measurement framework.

Consider four broad dimensions.

Reach

Did the intended audience discover the knowledge?

Use

Did visitors read, download, calculate, compare or complete?

Understanding

Did the page answer the question and lead towards relevant knowledge?

Organisational Value

Did the interaction contribute to learning, adoption, enquiry, participation or real-world action?

Not every outcome can be measured automatically.

Some require interviews, surveys, field observation or professional judgement.

Programming Impact

This requires:

• customised dashboards, 

• qualitative data fields, 

• outcome tracking, 

• and reporting that combines digital and organisational evidence. 

________________________________________ 

Rule 15.14; Protect Visitor Privacy in Analytics

The Rule

Collect only the analytics information required for legitimate improvement and handle it responsibly.

Why This Rule Exists

Measurement can easily become surveillance.

A website may collect:

• identity, 

• device information, 

• location, 

• behaviour, 

• search history, 

• form responses, 

• and third-party tracking data. 

Much of this may be unnecessary.

The organisation should ask:

What decision will this information help us make?

If no clear answer exists, the information may not need to be collected.

Analytics should be proportionate to the website’s purpose.

A public knowledge library may not need invasive individual profiling.

Aggregate information may be sufficient.

Sensitive tools require even greater care.

A career assessment, farm-business calculator or health-related survey may reveal personal information.

Such data should not automatically be shared with advertising systems.

What Most Programmers Do

Multiple analytics, advertising and behavioural tools are installed without a clear data map.

The organisation cannot explain what information is collected or where it goes.

Better Practice

Document:

• analytics tools, 

• data collected, 

• purpose, 

• retention period, 

• third-party access, 

• consent basis, 

• and deletion process. 

Prefer aggregate and anonymised measurement where individual identity is unnecessary.

Respect visitor choices.

Programming Impact

This requires:

• privacy-aware configuration, 

• consent management, 

• data minimisation, 

• retention controls, 

• third-party script review, 

• and secure analytics access. 

________________________________________ 

Rule 15.15; Separate Human Visitors from Automated Traffic

The Rule

Do not treat every request, page view or download as genuine human engagement.

Why This Rule Exists

Websites receive traffic from:

• search crawlers, 

• AI crawlers, 

• monitoring systems, 

• spam bots, 

• security scanners, 

• link-preview services, 

• and automated download tools. 

This traffic can distort reports.

A document may appear to have thousands of downloads because one bot requested it repeatedly.

A page may appear popular because monitoring software checks it every few minutes.

The organisation should not make decisions based on inflated activity.

What Most Programmers Do

All requests are counted equally.

Better Practice

Use reasonable bot filtering.

Compare:

• analytics data, 

• server logs, 

• user-agent patterns, 

• request frequency, 

• and completed human actions. 

No filtering system will be perfect.

The purpose is to avoid obvious distortion.

Programming Impact

This requires:

• bot classification, 

• rate analysis, 

• server-log integration, 

• duplicate-event controls, 

• and transparent reporting of estimated human traffic. 

________________________________________ 

Rule 15.16; Use Alerts for Important Failures and Unusual Changes

The Rule

The system should notify responsible people when important technical or behavioural changes require attention.

Why This Rule Exists

Dashboards are useful only when someone looks at them.

Some problems require faster attention.

Examples include:

• website unavailable, 

• sudden decline in indexed pages, 

• sitemap failure, 

• important document download broken, 

• large increase in server errors, 

• calculator completion collapsing, 

• unexpected traffic from spam, 

• or a major page losing visibility. 

Alerts help the organisation respond before the problem continues for weeks.

However, too many alerts create fatigue.

Every minor fluctuation should not generate an emergency.

What Most Programmers Do

Either no alerts exist or hundreds of low-value notifications are generated.

Better Practice

Create alerts only for meaningful conditions.

Define:

• threshold, 

• duration, 

• responsible person, 

• response process, 

• and escalation. 

For example:

Alert the technical administrator if more than 5% of public document downloads fail for two consecutive hours.

This is more useful than:

Alert whenever one download fails.

Programming Impact

This requires:

• monitoring thresholds, 

• notification routing, 

• alert suppression, 

• escalation rules, 

• and incident records. 

________________________________________ 

Rule 15.17; Combine Quantitative Analytics with Visitor Feedback

The Rule

Use numbers and direct human feedback together when deciding what to improve.

Why This Rule Exists

Analytics shows what happened.

It does not always explain why.

A page may have a high abandonment rate.

Possible reasons include:

• the answer was found immediately, 

• the page was confusing, 

• the visitor distrusted the source, 

• the form asked too much, 

• or the site loaded slowly. 

Direct feedback can help explain the numbers.

Simple mechanisms may include:

Was this page useful?

Did you find what you were looking for?

What information is missing?

Was the calculator result understandable?

The questions should remain brief and optional.

What Most Programmers Do

Either only analytics is used or large surveys interrupt every visitor.

Better Practice

Use small, contextual feedback opportunities.

Connect the response with the page or tool being reviewed.

Do not ask for identity unless follow-up is genuinely needed.

Review comments alongside performance data.s

Programming Impact

This requires:

• page-specific feedback, 

• optional comments, 

• privacy-conscious storage, 

• sentiment and topic review, 

• and integration with editorial workflows. 

________________________________________ 

Rule 15.18; Turn Measurement into an Improvement Workflow

The Rule

Analytics should lead to assigned actions, decisions and follow-up rather than remaining inside reports.

Why This Rule Exists

A dashboard does not improve a website.

People do.

An organisation may repeatedly observe:

• zero-result searches, 

• low tool completion, 

• outdated pages, 

• broken links, 

• or high mobile abandonment. 

If no one is responsible for acting, measurement has little value.

A proper improvement cycle may include:

1. Observe the issue. 

2. Diagnose the likely cause. 

3. Assign responsibility. 

4. Make a change. 

5. Measure the result. 

6. Preserve the learning. 

7. Repeat where necessary. 

For example:

Observation

Many visitors search for “summer rooftop garden.”

Diagnosis

The website contains related knowledge, but it is spread across several pages.

Action

Create a summer-preparation guide and connect existing resources.

Measurement

Review searches, page visits and checklist downloads after publication.

This turns visitor behaviour into organisational learning.

What Most Programmers Do

Monthly reports are circulated.

No decision log or action ownership exists.

Better Practice

For every significant insight, record:

• finding, 

• evidence, 

• proposed improvement, 

• responsible person, 

• expected outcome, 

• implementation date, 

• and review date. 

Not every finding requires action.

But every action should have a reason.

Programming Impact

This requires:

• analytics-to-task workflows, 

• issue ownership, 

• change records, 

• review dates, 

• and outcome comparison. 

________________________________________ 

Rule 15.19; Preserve Historical Analytics When the Website Changes

The Rule

Website redesigns, URL changes and analytics-tool migrations should not erase the organisation’s ability to understand long-term performance.

Why This Rule Exists

Knowledge systems develop over years.

The organisation may want to understand:

• which topics grew, 

• how audience interests changed, 

• which documents remained useful, 

• and whether a redesign improved discovery. 

Historical comparison becomes difficult when:

• page URLs change, 

• content identifiers change, 

• analytics accounts are replaced, 

• tracking definitions change, 

• or old reports disappear. 

A new URL should still be recognisable as the continuation of an earlier page where appropriate.

What Most Programmers Do

A redesign begins with a new analytics setup.

Old performance becomes disconnected.

Better Practice

Preserve:

• old and new URL mappings, 

• stable content IDs, 

• metric definitions, 

• historical exports, 

• tool migration dates, 

• and major methodology changes. 

When a metric changes definition, do not compare the numbers as though they are identical.

Programming Impact

This requires:

• persistent content identifiers, 

• historical data exports, 

• migration documentation, 

• redirect mapping, 

• and versioned analytics definitions. 

________________________________________ 

Rule 15.20; Review the Knowledge Ecosystem as a Whole

The Rule

Measure not only individual pages but also whether the entire website functions as a connected knowledge system.

Why This Rule Exists

A strong page can still exist inside a weak ecosystem.

Visitors may read it but fail to discover:

• the author, 

• related evidence, 

• supporting documents, 

• relevant tools, 

• deeper guidance, 

• or the next logical subject. 

The organisation should therefore examine system-level questions.

Are major knowledge areas easy to discover?

Do pillar pages lead towards useful resources?

Do FAQs connect to detailed explanations?

Do case studies connect to technical guidance?

Do downloads have proper landing pages?

Do author profiles show relevant work?

Do interactive results recommend suitable next steps?

Do important pages receive internal links?

This is the difference between measuring webpages and measuring a Knowledge Visibility Ecosystem.

What Most Programmers Do

Each page is evaluated independently.

Relationships receive little attention.

Better Practice

Create ecosystem-level indicators such as:

• percentage of important pages with internal links, 

• percentage of documents connected to relevant articles, 

• percentage of current pages with identified authors, 

• proportion of tools with completed result pathways, 

• number of orphan pages, 

• and number of overdue content reviews. 

These indicators reveal whether the architecture itself remains healthy.

Programming Impact

This requires:

• relationship audits, 

• content-health scoring, 

• CMS reporting, 

• cross-content analytics, 

• and periodic ecosystem reviews. 

________________________________________ 

Suggested Measurement Frameworks

This framework should not become a rigid scoring system.

It is a reminder that website success has several dimensions.

 ________________________________________ 

Suggested CMS and Analytics Structures

The analytics system and CMS should not operate as completely separate worlds.

Where possible, content owners should be able to view useful performance information directly against the page or document they manage.

They should not need to become professional analysts merely to understand whether their knowledge is being used.

________________________________________ 

A Practical Monthly Review Process

A useful monthly review may examine five areas.

1. Knowledge Discovery

Review:

• most visited pages, 

• pages gaining or losing visibility, 

• external search queries, 

• internal search terms, 

• and zero-result searches. 

Ask:

What are visitors trying to understand?

2. Visitor Use

Review:

• downloads, 

• calculator completions, 

• quiz completions, 

• form abandonment, 

• related-reading clicks, 

• and repeat visits. 

Ask:

Are visitors using the knowledge or merely arriving?

3. Content Health

Review:

• overdue updates, 

• pages with no authors, 

• outdated documents, 

• orphan pages, 

• duplicate content, 

• and low-traffic important pages. 

Ask:

Is the knowledge still reliable and discoverable?

4. Technical Health

Review:

• broken links, 

• failed downloads, 

• server errors, 

• slow pages, 

• crawl problems, 

• and mobile usability issues. 

Ask:

Are technical barriers preventing access?

5. Improvement Actions

Select a manageable number of priorities.

For each action, record:

• issue, 

• evidence, 

• proposed change, 

• owner, 

• deadline, 

• and follow-up measure. 

The objective is not to produce the largest report.

It is to create the clearest improvement decisions.

________________________________________ 

A Practical Example

Suppose an organisation publishes:

Rooftop Garden Summer Readiness Assessment

During the first month, the following is observed:

• 1,200 visitors open the assessment. 

• 830 begin it. 

• 310 complete it. 

• 290 receive “Moderately Prepared.” 

• 180 leave at the question asking for a mobile number. 

• Only 35 open the recommended summer watering guide. 

• Mobile completion is much lower than desktop completion. 

A weak analysis might say:

The assessment received 1,200 visitors.

A useful analysis would identify several issues.

Issue 1: High abandonment before completion

Possible cause: Too many questions or mobile difficulty.

Issue 2: Abandonment at mobile-number request

Possible cause: Personal information appears unnecessary.

Issue 3: Low use of recommended guidance

Possible cause: Result-page links are not prominent or specific enough.

Issue 4: Most visitors receive the same result

Possible cause: Scoring thresholds may be too broad.

Possible improvements:

• remove mandatory mobile-number collection, 

• simplify the mobile interface, 

• review scoring logic, 

• display the three personal gaps more prominently, 

• and connect each gap with one specific guide. 

The revised tool can then be measured again.

This is continuous improvement.

The analytics did not merely report behaviour.

It helped redesign the visitor experience.

________________________________________ 

Chapter Summary

Measurement is the final chapter of this handbook, but it is not the end of the website-development process.

It is the mechanism through which the process begins again.

A website publishes knowledge.

Visitors interact with it.

Analytics reveals what happened.

Feedback helps explain why.

The organisation improves the content, structure or technology.

The next cycle produces new learning.

This is how a Knowledge Visibility Ecosystem remains alive.

Measurement should examine:

• which pages visitors discover, 

• how they move through the website, 

• what they search for, 

• which documents they download, 

• where they abandon interactive tools, 

• which pages remain hidden, 

• which links are broken, 

• and whether AI systems represent the organisation accurately. 

However, success should never be judged only by total visitor numbers.

A small professional audience may create substantial real-world impact.

A specialised document may remain important even when traffic is modest.

A quick-answer page may be successful precisely because visitors do not spend long on it.

Metrics must therefore be interpreted according to purpose.

The programmer’s responsibility is to build measurement systems that are technically reliable, privacy-conscious and connected with meaningful organisational decisions.

The organisation’s responsibility is to act upon what those systems reveal.

Together, they must ensure that analytics does not become a collection of impressive charts with no practical consequence.

The true purpose of measurement is improvement.

It helps the organisation recognise:

• what knowledge people need, 

• what they cannot find, 

• what they trust, 

• what they use, 

• where they struggle, 

• and what should be created or corrected next. 

An Organisation’s Knowledge Visibility Ecosystem is never complete.

It becomes stronger through continuous observation, reflection and improvement.

That is also the final principle of this handbook:

Do not merely build a website and measure its traffic. Build a knowledge ecosystem that continuously learns how to serve people better