Why This Chapter Matters
Once the website architecture has been created, the programmer has to decide how the supplied content will appear on each page.
This does not mean deciding what the organisation should say. Content philosophy, editorial tone and subject knowledge usually come from the organisation, writer or content team.
The programmer’s responsibility is different.
The programmer must ensure that the supplied content is presented in a structure that is:
• easy for visitors to read,
• easy to navigate,
• easy to understand on mobile devices,
• easy for search engines to interpret,
• easy for AI systems to extract,
• and easy for the organisation to update later.
A page may contain excellent information and still perform poorly if the presentation structure is weak.
For example, the main answer may be hidden below a large banner. Headings may be selected according to font size rather than meaning. Long paragraphs may be placed inside visually attractive blocks that are difficult to read. Important information may be hidden inside tabs or expandable sections. Tables may become unusable on mobile screens. Author and date information may be missing or unclear.
These are not content-writing problems. They are implementation problems.
The programmer should therefore treat every webpage as a structured information document—not merely as a visual screen.
This chapter explains how supplied content should be converted into pages that remain readable, meaningful, accessible and technically understandable.
________________________________________
Rule 3.1; Build Every Page Around a Clear Heading Structure
The Rule
Use one clear H1 (HTML heading levels) for the main subject of the page, followed by H2 and H3 headings in a logical sequence.
Why This Rule Exists
Headings are not merely formatting tools.
They define the structure of the page.
The H1 identifies the main subject. H2 headings divide the subject into major sections. H3 headings divide those sections into smaller parts.
Visitors often scan headings before deciding whether to read the full page. Screen readers use headings to help users navigate. Search engines and AI systems use them to understand how different parts of the content relate to one another.
When headings are used inconsistently, the page may look acceptable visually but remain structurally confusing.
What Most Programmers Do
Heading levels are often selected according to appearance.
A programmer may use an H2 because its font size looks suitable.
Another section may use an H4 because the design template gives it the desired colour.
Some pages may contain several H1 headings because every major block has been styled as a page title.
This creates a visual design, but not a meaningful document structure.
Better Practice
Every normal content page should have one principal H1 that describes the page.
Use H2 for major sections within that page.
Use H3 only when a section under an H2 requires further division.
Avoid skipping levels without a structural reason.
For example:
• H1 – Main Page Title
o H2 – First Major Section
H3 – Supporting Subsection
H3 – Supporting Subsection
o H2 – Second Major Section
o H2 – Third Major Section
Control appearance through CSS rather than by choosing the wrong heading level.
Programming Impact
A logical heading structure improves:
• semantic HTML,
• accessibility,
• screen-reader navigation,
• search interpretation,
• AI extraction,
• table of contents generation,
• page consistency,
• and future template maintenance.
________________________________________
Rule 3.2; Present the Main Answer Before Decorative Material
The Rule
Do not make visitors cross large banners, animations, sliders or promotional blocks before reaching the main purpose of the page.
Why This Rule Exists
A visitor normally opens a page because they want information, an answer, a service or an action.
The page should therefore reveal its purpose quickly.
Large decorative elements may look impressive, but they often push the real information far below the visible screen. This is especially damaging on mobile devices, where a large banner may occupy the entire first screen.
Search engines and AI systems also benefit when the opening part of the page clearly identifies the subject and provides a direct introduction.
The first visible content should confirm that the visitor has reached the correct page.
What Most Programmers Do
Many page templates begin with:
• a full-screen image,
• an automatic slider,
• a promotional video,
• animated statistics,
• multiple call-to-action buttons,
• or decorative blank space.
The actual answer or page introduction may appear much later.
This often happens because the homepage design style is reused on every internal page.
Better Practice
Near the beginning of the page, display:
• the page title,
• a brief introductory explanation,
• the direct answer or purpose,
• and the most important action where one is required.
Decorative media may support the content, but it should not delay access to it.
For informational pages, the visitor should understand within the opening screen:
• what the page is about,
• whether it answers their question,
• and what they can do next.
Programming Impact
This influences:
• page templates,
• content ordering,
• mobile layouts,
• component priority,
• loading performance,
• accessibility,
• and machine interpretation.
________________________________________
Rule 3.3; Break Long Content into Readable and Addressable Sections
The Rule
Do not present long content as one continuous block say more than 150-200 words. Divide it into meaningful sections that can be read, linked and updated independently.
Why This Rule Exists
Reading on a screen is different from reading a printed book.
Visitors scan.
They pause.
They jump between sections.
They return later.
They may arrive directly at a particular part of a page through a search result or shared link.
Long, uninterrupted paragraphs create visual fatigue. They also make it difficult to locate a specific answer.
Clear sections make the page easier to understand without changing the supplied content itself.
Each important section should also be addressable through a stable anchor link wherever practical. This allows visitors, search engines and AI systems to refer directly to the relevant portion of a long page.
What Most Programmers Do
Supplied Word documents are often pasted into the CMS as a single content block.
Paragraphs may remain excessively long.
Section headings may not receive IDs.
The entire page becomes one large HTML field with very little internal structure.
The page technically displays the content, but does not help the visitor use it.
Better Practice
Divide long pages using:
• clear H2 and H3 headings,
• reasonably sized paragraphs,
• short explanatory blocks,
• lists where items are genuinely separate,
• tables where information must be compared,
• and meaningful spacing between sections.
Assign stable and readable anchor IDs to important headings.
For example:
#cost-of-installation
#maintenance-requirements
#frequently-asked-questions
Avoid automatically generated anchors that change whenever the page is edited.
Programming Impact
This improves:
• readability,
• deep linking,
• internal navigation,
• search-result linking,
• AI citation,
• accessibility,
• content maintenance,
• and reusable page components.
________________________________________
Rule 3.4; Use the Correct Presentation Element for the Information
The Rule
Present information according to its meaning—not merely according to the appearance the designer wants.
Why This Rule Exists
Different types of information require different presentation structures.
A paragraph explains an idea.
A list presents separate items.
A table supports comparison.
A figure explains visually.
A quotation identifies someone else’s words.
A definition identifies the meaning of a term.
When every type of information is placed inside generic visual boxes, the meaning may remain obvious to a human visitor but become unclear to screen readers, search engines and AI systems.
Semantic presentation helps machines understand not only what text is present, but what role it performs.
What Most Programmers Do
Programmers frequently build every content block using generic <div> elements.
Lists are manually created using symbols.
Tables are reproduced through columns and spacing.
Headings are created by enlarging paragraph text.
Important text may be placed inside images because it is easier to match the design.
The page looks correct, but its underlying structure is weak.
Better Practice
Use appropriate HTML elements wherever possible:
• headings for section titles,
• paragraphs for explanations,
• ordered lists for sequences,
• unordered lists for grouped items,
• tables for genuine comparison,
• captions for tables and figures,
• blockquotes for attributed quotations,
• buttons for actions,
• and links for navigation.
Do not use a table merely to arrange a page layout.
Do not convert important textual information into an image.
Where comparison is important, use a properly marked-up table with:
• column headings,
• row headings where required,
• a caption,
• clear labels,
• and a mobile-friendly display method.
Programming Impact
Correct presentation elements improve:
• semantic HTML,
• accessibility,
• responsive behaviour,
• search interpretation,
• AI understanding,
• content extraction,
• template consistency,
• and future redesign.
________________________________________
Rule 3.5; Use Tables, Tabs and Expandable Sections Carefully
The Rule
Do not hide or distort important information merely to make a page appear shorter or more attractive.
Why This Rule Exists
Tables, tabs, accordions and expandable sections can improve a page when used for the right purpose.
They can also make information difficult to access.
Large tables may become unreadable on mobile devices. Important answers hidden inside collapsed sections may be overlooked. Tabs may fail to work properly with keyboards or screen readers. Content loaded only after a user clicks may not be readily available to automated systems.
The question is therefore not whether these features should be used. The question is whether they improve access to the information.
What Most Programmers Do
Long content is sometimes placed inside multiple accordion sections simply to reduce page length.
Comparative information is forced into cards because responsive tables require additional work.
Tabs are used to divide related content even when visitors need to compare the sections side by side.
In some cases, collapsed content is not included in the initial page code and is loaded only after interaction.
Better Practice
Use tables when visitors genuinely need to compare information across rows and columns.
For wide tables on smaller screens, consider:
• controlled horizontal scrolling,
• fixed headings,
• responsive transformations,
• or a carefully designed alternate mobile view.
Use expandable sections mainly for:
• supplementary explanations,
• detailed technical notes,
• optional examples,
• and frequently asked questions.
Important core information should remain visible.
Where accordions or tabs are used:
• keep the content available in the page structure,
• use accessible controls,
• support keyboard operation,
• clearly show the open or closed state,
• and ensure links can open the relevant section directly.
Programming Impact
This affects:
• responsive design,
• JavaScript behaviour,
• accessibility,
• content rendering,
• crawlability,
• mobile usability,
• deep linking,
• and component testing.
________________________________________
Rule 3.6; Provide Navigation Within Long Pages
The Rule
When a page becomes long or contains many sections, provide visitors with a clear way to move within the page.
Why This Rule Exists
A long page is not automatically a bad page.
Some subjects require detailed explanations, procedures, case studies, reference material or multiple questions and answers.
The problem begins when the visitor has no overview of what the page contains and no way to reach the required section quickly.
A table of contents turns a long page into a navigable document.
It also reveals the structure of the page before the visitor begins reading.
What Most Programmers Do
Long pages are displayed as continuous vertical content.
Visitors have to scroll repeatedly to find a particular section.
After reading a section near the bottom, they may have no convenient way to return to the beginning or move to another part.
Better Practice
For long and structured pages, provide a table of contents based on the H2 and, where useful, H3 headings.
Each entry should link to a stable section anchor.
The table of contents may be:
• displayed near the beginning,
• placed in a side panel on larger screens,
• made collapsible on mobile devices,
• or kept visible while the visitor scrolls.
Where appropriate, also provide:
• “Back to Top” links,
• previous and next section links,
• and direct links to frequently used sections.
The table of contents should preferably be generated from the actual heading structure so that it remains accurate when the page is updated.
Programming Impact
This improves:
• long-page usability,
• deep linking,
• heading discipline,
• page navigation,
• mobile access,
• accessibility,
• and content maintenance.
________________________________________
Rule 3.7; Show the Context and Status of the Content Clearly
The Rule
Every substantial page should clearly identify who produced the content, when it was published or updated, where it belongs and what related information is available.
Why This Rule Exists
Content does not exist in isolation.
Visitors may need to know:
• who wrote or approved it,
• when it was published,
• whether it has been updated,
• which category it belongs to,
• and where they can continue reading.
This context becomes especially important for technical, legal, medical, financial, agricultural or time-sensitive information.
Search engines and AI systems also use these signals to understand the source, freshness and relationship of the information.
The programmer may not decide the author or publication date, but must provide a reliable system for recording and displaying them.
What Most Programmers Do
Author information is sometimes omitted from the database.
Publication and update dates are displayed inconsistently.
Categories appear only in the admin panel and not on the public page.
Related content is selected manually and becomes outdated.
Some websites automatically change the displayed date whenever a minor edit is made, making old content appear newly published.
Better Practice
Where relevant, provide structured fields for:
• author or responsible organisation,
• original publication date,
• latest meaningful update date,
• category,
• sub-category,
• tags,
• content status,
• and related pages.
Clearly distinguish between:
• “Published on”
• and “Last updated on”
Do not change the original publication date merely because punctuation, formatting or a minor technical correction was made.
Related content should be generated through meaningful category, tag or relationship data—not through random selection.
Programming Impact
This affects:
• database fields,
• CMS forms,
• content templates,
• structured data,
• author archives,
• category pages,
• related-content logic,
• and update history.
________________________________________
Chapter Summary
The programmer is not expected to rewrite the organisation’s content.
The programmer is expected to present that content correctly.
A well-structured page tells visitors immediately what the page is about. It uses headings to establish hierarchy, places the main answer before decoration, breaks long information into usable sections and selects presentation elements according to meaning.
It also ensures that long pages can be navigated, important content is not carelessly hidden and every substantial page carries enough information about its source, date, category and relationship to other pages.
A webpage should not be treated merely as a collection of visual blocks.
It should be treated as a structured document that can be read by people, interpreted by machines, maintained by organisations and discovered long after it was first published.
