PDF or Web Page? How to Publish a Brochure, Menu, Price List or Instructions

The short answer

For most small businesses, publish the content as an HTML web page first. A web page is the normal path people take to read, search, tap a phone number and complete a next step. Add a PDF only when printing, a fixed layout or an offline copy is genuinely useful to your readers. If you publish both, name one person who updates both every time the content changes.

That is practical advice, not a rule. The sections below separate what the sources say from what is a sensible default for a small team.

Why HTML is the better default

A well built HTML page can adapt to the screen, the text size and the browser settings your visitor already uses. HTML is not automatically responsive or accessible, though. It still needs real headings, readable contrast, sensible links and a check on a phone. Done properly, the page can sit beside your contact details, booking link or order form, so a reader can act on what they just read without hunting through a separate file.

It is also usually easier to correct. You edit one page and publish it, and the change goes live once your site's normal publishing step is complete. That step might be instant or might involve review, depending on how your site is set up.

Source fact: GOV.UK guidance on publishing accessible documents recommends HTML wherever possible so that documents use a reader's custom browser settings, and says PDF documents can make content harder to find, use and maintain (https://www.gov.uk/guidance/publishing-accessible-documents). That guidance is written for government publishers. It is a well reasoned example of good practice, but it is not a legal authority for private businesses and it is not a universal ban on PDFs.

When a PDF is genuinely useful

A PDF earns its place when the document itself is the useful thing. Good reasons include:

• People will print it and want the page to look the same on paper.
• The layout matters, such as a folded brochure or a poster style menu.
• Someone may need it offline, or may forward it to a colleague or family member.
• You need a stable snapshot of a particular version, such as terms that applied on a given date.

Weak reasons include "it was already designed in a layout program" or "it was quicker to upload." If the only reason is convenience for you, the reader may pay for it.

A PDF can open in the browser and can contain working links, so it is not a dead end. On a phone, though, it may need a document viewer or pinch zoom to read comfortably, and it sits apart from the navigation and actions of the rest of your website.

What about search?

You may worry that a PDF will not show up in search. That is not quite right. Source fact: Google documents Adobe PDF as a supported encoded file type that it can index (https://developers.google.com/search/docs/crawling-indexing/indexable-file-types). Being a supported type is about eligibility. It does not guarantee that a file will be indexed or that it will rank well. Practical view: a web page gives you the surrounding website navigation and actions, such as a booking link or contact details, right beside the content, which is useful to visitors whichever way they arrive.

Accessibility: a tag is not proof

If you do publish a PDF, check it rather than assuming it works. Source facts from the W3C technique on tab and reading order in PDF: reading order is determined primarily by the tag order of document elements, and pages with complex layouts such as graphics, tables, footnotes, sidebars and form fields may not convert to tagged PDF in the correct order. The technique describes two separate checks. Reading the file with a screen reader or a tool that reads aloud checks that content is in the right reading order. Using the keyboard checks that focusable content, such as links and form fields where present, follows a logical order (https://www.w3.org/WAI/WCAG22/Techniques/pdf/PDF3).

These are specific checks, not a complete accessibility audit, and one does not replace the other. You do not need to tab through every paragraph. Tab through the links and form fields, and listen to the text.

Practical consequence: text that can be selected or tags that exist do not by themselves show a document is usable. Selectable text does not tell you whether it came from native source text or from scanned text with imperfect recognition. Check structure and accuracy. Two column menus and price tables are layouts where order can go wrong.

Source fact: GOV.UK also states that PDF and PDF/A cannot be made fully accessible to all users of assistive technology (https://www.gov.uk/guidance/publishing-accessible-documents, the same guidance cited above). That is one more reason to offer the same information as a web page.

Hypothetical decision examples

These are invented scenarios to show the reasoning, not real cases.

A cafe with a menu that changes weekly. Publish the menu as a web page. Add a printable PDF only if the cafe hands out paper copies, and replace both on the same day.

A tradesperson with a service list. Put the list on a page near the enquiry link so customers can act straight away. Offer a PDF only if customers often ask to forward it to a decision maker.

A studio with a designed brochure. Keep the brochure PDF for print and sharing, but put its key content in HTML so people searching on a phone can read it without opening a separate viewer.

A business with setup instructions for a product. Use HTML for the steps, because people follow instructions while doing something else, and links, headings and updates matter. A print friendly PDF can be a secondary option.

Maintenance and version ownership

The real cost of a second format is keeping it current. Before publishing both, decide:

• Who owns the master content? Pick one source of truth, ideally the web page.
• Who regenerates the PDF when it changes, and how soon?
• What happens to older files? Before removing or redirecting a superseded public copy, consider whether you need to keep it for records or archival reasons. If you do retire it, point any redirect to the current version of the same content, never to something unrelated.
• How will people know which version they have? Put a visible "last updated" date in the page and in the PDF.

If nobody can answer the first two questions, publish only the web page. When deciding whether a download is worth it, weigh how often the content changes and remember you cannot recall copies people have already saved. Frequent changes raise the cost of every download, but even a slow changing file needs an owner.

Practical launch checklist

1. Publish the content as a web page with real headings, lists and a clear title.
2. Put the next action (call, book, order, enquire) next to the content.
3. Decide whether a PDF is truly needed, and write down why.
4. If yes, build the PDF from the same source text, not a separate rewrite.
5. Listen to the PDF with a screen reader or read aloud tool to check reading order, and use the keyboard to check links and any form fields.
6. Use a short, descriptive file name and link text that says what the file is.
7. Show an updated date on both formats.
8. Name the person responsible for updating both, and set a review reminder.
9. Decide what to do with superseded files, considering record keeping before removal or redirect.
10. Test on a phone and print the page or PDF once to see the result.

If the page is part of a larger site project, a website project brief is a good place to record which documents need which format and who owns them.

FAQs

Can I just upload my designed brochure PDF and skip the web page? You can, and it may be fine for a document that is mainly printed. The trade offs are that readers may need a document viewer or pinch zoom on a phone, and the file sits apart from your site's navigation and next steps. A short web page covering the key points, with the PDF as an optional download, often serves both visitors and you better.

Is a PDF with selectable text accessible? Not necessarily. Selectable text only means the text can be selected. It does not show the text is accurate, that it came from clean source text rather than imperfect scanned recognition, or that headings and order make sense. Check the structure and accuracy, listen to the reading order, and use the keyboard on links and form fields. Repeat the checks whenever the file changes.

Should I worry that two versions will disagree? Yes, that is the main risk. Keep one master source, produce the other format from it, date both and assign an owner. If your team cannot commit to that, publish HTML only. If you are planning a website and want to talk through how documents like these should appear on it, you can start a conversation through work with me.

Sources

• GOV.UK, Publishing accessible documents: https://www.gov.uk/guidance/publishing-accessible-documents (government publishing guidance, not legal authority for private businesses)
• W3C, Technique PDF3, Ensuring correct tab and reading order in PDF documents: https://www.w3.org/WAI/WCAG22/Techniques/pdf/PDF3
• Google Search Central, File types indexable by Google: https://developers.google.com/search/docs/crawling-indexing/indexable-file-types