Planning an Investor Relations Website: Content, Downloads and Update Ownership

An investor relations website needs a clear route to current information, dependable access to past documents and a publishing process the company can operate. Start with those tasks before choosing the homepage treatment.

For a Hong Kong organisation, the brief should identify the required languages, document categories, content owners and approval steps. The company’s IR, company-secretarial and professional advisers should confirm publication obligations and timing. The design and development brief can then turn those confirmed requirements into a usable website.

Start with the investor’s task

Write down what someone should be able to do when they arrive:

• Find the latest financial report
• Locate a particular announcement or presentation
• Compare reporting periods without opening every file
• Understand the company’s business
• Find the appropriate investor contact

These tasks help decide navigation and page priorities. A returning visitor may want one document immediately, while a new reader needs background. Give both a direct route.

Test proposed labels with someone outside the project. Ask them where they would look for an interim report or an older presentation. Their hesitation can reveal a naming problem before the design is built.

Build the document inventory first

Gather the existing archive into a register. For each item, record its approved title, category, publication date, reporting period, language, file location and responsible owner.

Keep the publication date and reporting period as separate fields. A report published this year may describe the previous year. Using one field for both can make sorting and archive labels confusing.

Identify duplicate files, missing language editions and links that point to a previous hosting service. Ask the content owner which version is authoritative before moving or removing anything.

A useful report listing might show the report title, period, language and file format. Decide whether readers also need file size, chapter downloads or a related presentation. Apply the same structure consistently across the archive.

Make language versions easy to distinguish

Define English, Traditional Chinese and any other required editions at the start. Record how language switching should work for document listings and individual pages.

A visitor switching language should understand whether a matching document exists. Agree what the interface will show when an edition is unavailable, rather than silently sending them to a different period or another language.

Use a terminology sheet for company names, document categories and reporting labels. Have the language reviewer check the complete page, including menus, buttons, dates and download names.

Review long document titles on a phone. A title that fits in English may wrap differently in Chinese. Keep the full title readable and place secondary details where they remain easy to scan.

Give publishing a clear owner

Define who prepares an update, who checks its content and who authorises publication. Those may be different people.

For example, a new report might move through these steps:

1. The content owner supplies the approved file and listing details
2. A reviewer checks the document, language and reporting period
3. The publisher previews the page and tests the download
4. The authorised approver confirms release
5. The publisher checks the public page after publication

Record how urgent corrections will be handled. A publishing team needs to know whom to contact, which version has approval and how to confirm the correction reached the live site.

Ask the developer to demonstrate this workflow with representative content. Seeing an editor complete an update is more useful than being told the CMS supports uploads.

Design readable pages and useful downloads

Document access should be clear in the page text. A label such as “Annual Report 2025, English, PDF” gives a reader more information than several identical “Download” links. W3C’s link-purpose guidance explains why meaningful link wording helps people understand destinations.

Use headings that reflect the page’s organisation. W3C’s headings tutorial describes how heading structure supports navigation, including with assistive technology.

Review the documents as well as their links. Agree the accessibility scope for PDFs, tables and other files with the appropriate specialists. A clear website listing cannot resolve problems inside a document.

Test the agreed tasks using a keyboard and on the intended mobile and desktop layouts. Include opening files, returning to the archive and identifying the correct edition.

Decide what belongs in the CMS

Ask which content the company expects to update itself: report listings, announcements, contact information, presentations or general company pages.

For each item, agree the editable fields, required checks and preview behaviour. Useful controls might include a required language label or a warning when a document has no reporting period. The exact setup should follow the content model.

If a market-data feed or another external service is requested, identify its provider, update behaviour, licence and support responsibility. Include how the page behaves if that service is unavailable. Confirm those requirements before treating the feed as part of the website package.

Plan the archive and ongoing support together

Set out how existing links will be handled during migration. Identify important document URLs and pages that people may have bookmarked or shared.

Agree who checks those routes, maintains the hosting arrangement and handles future content updates. Also record who owns the domain, manages renewals and can access the necessary administration accounts through an approved handover process.

Miracle’s published China Graphite Group case brings corporate website design and development together with ongoing IR services, hosting, maintenance and content management. It is a useful example of including the operating relationship in the project discussion.

Use a practical launch checklist

Before release, ask the project team to verify:

• Current and archived documents open correctly
• Titles, dates, reporting periods and language labels match approved content
• Important old links reach the intended destination
• An editor can complete the agreed publishing workflow
• Navigation and downloads work on the agreed devices
• Support contacts and update responsibilities are documented

Retain the tested content register and handover instructions. They provide a starting point for the next reporting cycle.

What to include in your IR website brief

Share the existing website, document archive, required languages and typical update requests. Identify the content approvers, the publishing team and any fixed launch or reporting dates.

Include examples of tasks investors should be able to complete. Miracle’s website design and development services can be discussed around that content model and operating workflow. Send your brief with the material you already have and the decisions still to be made.