Should my class schedule be a PDF?

What Google actually does with a PDF

Google indexes PDFs. Adobe Portable Document Format sits on its published list of indexable file types, with a caveat worth reading twice: those formats are “binary files or complex containers that require a specific parser to extract the human-readable text.”

So the words get read. What the file never gets is the rest of what a page gets.

Google indexes and ranks the mobile version of your site, crawled with the smartphone agent, and points at responsive design as the way to serve it. A PDF has exactly one layout, sized for a sheet of Letter paper, and it is that same layout on a six-inch screen.

Then schema. Structured data has to be “coded using in-page markup on the page that the information applies to.” A PDF has no in-page markup to put it in, so nothing on your schedule can be declared as a class, a program, a location, or a price. You hand the engine a picture of a grid and hope it infers a school.

And the file is a dead end. An HTML schedule links out from the row that mentions the thing — kids’ BJJ to the kids’ page, the 6am to the trial page. A PDF links to nothing. Whatever traffic it takes, it keeps.

The format survives because it’s the default output of print-shaped tools, and because nobody emails you to say they couldn’t read your schedule. They just leave.

The 9pm problem

Nielsen Norman Group re-published the verdict on this in 2020. PDF layouts are “optimized for a printed sheet of paper, not a mobile browser,” which leaves people to “pinch, zoom, squint, and scroll around out of context.” Their fix is the obvious one: put the content in an HTML page, and offer the PDF as a download for the two people who want to print it.

Picture who that is on your site. A parent, one hand, phone, 9pm, working out whether there’s a kids’ class on Tuesday that doesn’t collide with swimming. She taps the link, waits for a viewer to open a file, then pinches around a grid built for a printer looking for a word she isn’t sure you use — Little Tigers, Juniors, Kids Fundamentals. Somewhere in that sequence she goes back to the results page, where three other schools are waiting.

Accessibility fails the same way. Reflowing text to fit a different screen size, and exposing reading order to assistive technology, are functions of Tagged PDF — the tagging is the part that does the work. WebAIM’s position is blunt: “an untagged PDF would not be considered ‘accessible.’” Tagging is a deliberate step. An export is not a deliberate step.

Four ways schools publish a schedule

Format	On a phone	What an engine gets
PDF download	Downloads, opens in a viewer, keeps its Letter-sized layout	The text, eventually. No responsive layout, no schema, no links onward.
Screenshot of the grid	Pinch, zoom, and it goes blurry	Almost nothing. An image of text is not text.
Embedded software calendar	Whatever your vendor’s own layout does — you don’t control it	Not guaranteed to count as your page’s content at all.
HTML page you own	Reflows, filters by program and level, one tap to book	Headings, prices in text, schema, a link to every program page.

That third row is Google’s own wording, not a theory: its systems “would try to associate the sub-page’s content as a part of the primary page for indexing, but it’s not guaranteed, since both pages are normal HTML pages on their own too.”

Not a reason to rip the widget out. A reason not to let it be the only version of your schedule that exists.

If your software makes the schedule

Kicksite, Zen Planner, PushPress, Gymdesk and Mindbody all want to own the calendar, and for booking they should. Split the job.

The software keeps booking, attendance and the roster. Your site keeps the reading: a plain HTML page with the recurring weekly grid, filterable by program and by level, every row linking to the program page it belongs to, prices in text, and a trial button that hands off to the software. A weekly timetable changes a handful of times a year, not daily. Maintaining it in HTML is an edit, not a project.

If part of the calendar genuinely changes weekly — open mat, seminars, camp weeks — keep the widget for that block and the HTML grid above it.

The format is the easy half

Moving the grid into HTML fixes rendering, fixes accessibility, and gives an engine something quotable. It does not fix a schedule that only lists times.

So ask the harder thing about that page. Can a stranger tell which class they’re allowed into on day one? Does it say gi or no-gi, kids or adults, beginner or open mat? What does it cost? What happens if they turn up to the 6am — do they need a gi, is anyone expecting them?

A schedule that answers those is worth building a page around. A schedule that answers none of them is a wall of times, and converting it to HTML only makes the wall load faster.