What I Learned Building a Fast Printable Library with Next.js and Cloudflare

I have been working on Funboxie, a small printable library for coloring pages, worksheets, templates, and simple kids' activities.

At first glance, a printable site looks like a content project. In practice, it has many of the same operational problems as a documentation platform or a small SaaS marketing site: lots of URLs, lots of static assets, search traffic that depends on crawlability, and a user experience where speed matters more than fancy UI.

Here are a few lessons that have been useful while building and operating it.

1. Treat every URL like a product surface

A printable library is not just a homepage with a few posts behind it. Each page has its own job:

• a hub page helps users browse a category
• a detail page answers a specific search intent
• a printable asset needs to load reliably and be easy to use
• a sitemap needs to tell crawlers what is actually current

That made URL design more important than I expected. If a page is indexed, shared, or linked internally, it becomes a contract. When pages are removed or renamed, returning a clear 410 is often better than silently pushing users to an unrelated page.

For Funboxie, I found it more useful to improve pages that already had search signals than to keep creating new pages. Pages like coloring page hubs and printable templates can be quietly valuable if they load fast, explain what the user will get, and link to related resources.

2. Fast static-ish pages are still operational work

The stack is intentionally simple: Next.js for routing and page generation, deployed on Cloudflare with an OpenNext-style setup.

The operational goal is not novelty. It is boring reliability:

• pages should return 200 when they are meant to exist
• old removed pages should not create confusing crawler behavior
• sitemap URLs should match the live canonical site
• printable assets should not depend on a slow app path
• builds should catch type and routing mistakes before deploy

For this kind of site, I would rather have fewer moving parts than a complex CMS workflow. The content model can be lightweight as long as it produces stable pages and predictable metadata.

3. Search Console is a better backlog than intuition

It is tempting to brainstorm huge keyword lists. That can be useful, but it is easy to spend days creating pages that no one has validated yet.

A better early loop has been:

1. Check which pages already receive impressions.
2. Find high-impression, low-click queries.
3. Inspect whether the page title, intro, and related links actually match that intent.
4. Make a small improvement.
5. Wait long enough for search data to move.

This is slower than bulk publishing, but it keeps the backlog grounded. If a page already gets impressions for a query, the problem is often not discovery. The problem may be title clarity, page fit, internal links, or whether the asset is obvious enough above the fold.

4. Printable sites need asset discipline

With printables and coloring pages, the image or PDF is not decoration. It is the product.

That changes the usual content workflow. A page can have good text and still fail if the printable preview is unclear, the download path is confusing, or the asset URL is unstable.

The practical checklist I use is simple:

• Is the printable visible quickly?
• Is the page useful on mobile even if the final action happens on a printer?
• Are related pages linked in a way that helps browsing, not just SEO?
• Does the metadata describe the actual page, not a generic category?
• Are removed assets handled intentionally?

These are small details, but they compound across a large library.

5. The boring checks matter most

The highest-value checks so far have not been exotic:

• run the type checker before deployment
• run a production build before deployment
• spot-check the top URLs after deployment
• inspect 404 and 5xx examples before assuming the problem is current
• keep the sitemap clean

For a small site, this is enough to prevent many avoidable regressions.

Closing thought

Building Funboxie has been a reminder that "content site" does not mean "no operations." If the site depends on organic search, user trust, and downloadable assets, then routing, status codes, build quality, metadata, and asset delivery are part of the product.

The work is not glamorous, but it is the kind of work that makes a small website durable.