By Lucy Hitz, Director of Product Marketing, Pantheon

Where do you really manage your content?

For many, the answer is Google Docs, a tool deeply integrated into our workflows for content creation and collaboration. Yet, the bridge between content creation in Google Docs and its publication on a live website has often been fraught with manual, time-consuming steps.

In September 2025, we announced Public Preview (that means you can start your free enterprise-grade trial now) for Pantheon's Content Publisher to streamline this process, offering a direct flight from Google Docs to your live site.

This post will explore two primary approaches to integrating Content Publisher: building a new site with it from the ground up, and incorporating it into an existing site.

The Core Problem: Content Workflow

The traditional workflow for publishing content, from blog posts to documentation to author bios, often involves a multi-person operation.

As Steve Persch, Director of Developer Relations at Pantheon, noted in our recent webinar, available on demand now, "It is still true that writing long-form text in the professional world is a multiplayer game."

Google Docs excels at this collaborative editing, offering features like suggestion mode and ownership tracking. However, moving this polished content from Google Docs to a CMS like Drupal or WordPress has historically meant a cumbersome copy-and-paste routine, re-uploading images, and reformatting.

Implementing Content Publisher on a New Site (Next.js Example)

For new projects, especially those leveraging modern front-end frameworks, Content Publisher offers a straightforward implementation.

Direct Integration with Next.js

When starting fresh, you can use Content Publisher to power a Next.js site directly. Our documentation provides a "Next.js Getting Started tutorial" that guides you through setting up a starter Next.js codebase.

Key aspects of this approach:

• Google Docs as the source: The entire content of a page or post comes from a Google Doc.
• API-driven: Content is sent from Google Docs, through the Content Publisher API, to your Next.js front-end.
• Side-by-side preview: Content Publisher offers a compelling side-by-side preview mode, allowing content creators to see changes in Google Docs reflected instantly on a public website preview. This facilitates iterative editing and ensures the final output matches expectations before publishing.
• No traditional CMS: In some Next.js implementations, there might be no traditional CMS (like WordPress or Drupal) in the backend; Content Publisher effectively serves as the content management layer.

The "Google Doc is the Entity" Approach

In this new site scenario, the Google Doc itself becomes the primary entity for content. When you publish from the Google Doc, it directly creates the page or post on your site. This simplifies the content model and workflow significantly, as the content creator's primary interaction remains within Google Docs.

Implementing Content Publisher on an Existing Site

Integrating Content Publisher into an existing site, whether Drupal, WordPress, or Next.js, requires a slightly different approach but still offers significant benefits.

Drupal Implementation: Incremental Adoption

For existing Drupal sites, migrating thousands of articles to Google Docs might not be feasible or desirable. Pantheon advocates for incremental adoption.

Two primary strategies for Drupal:

1. Entity reference field: This approach allows you to introduce Content Publisher without overhauling your entire content structure.
   • Add an entity reference field to an existing content type (e.g., "Article" or "Recipe").
   • This field can then point to a Google Doc managed by Content Publisher.
   • You can choose to either augment an existing body field with content from the Google Doc or have the Google Doc entirely replace the body field's function for specific content.

This method allows you to eliminate the copy-pasting step for new content or selectively for existing content, while still leveraging your existing Drupal taxonomy (e.g., tags).

Consider the starter "Umami Food Magazine" site in Drupal as an example. New recipes or articles could be created in Google Docs and linked via an entity reference, while older content remains in Drupal's body fields. Your existing library will continue living on your site without change, and will be equally discoverable via search.

1. Intermixing at the search index level: For a more comprehensive integration, especially with a large volume of existing content, you can intermix traditional Drupal content nodes with documents from Content Publisher at the search index level.
   • This allows you to build views that seamlessly display both types of content.
   • This approach is suitable for scenarios where you want Content Publisher to power new content creation while still making all your historical content discoverable alongside it. This is the approach Pantheon is taking for their own blog (pantheon.io).

WordPress Implementation: Native Side-by-Side Content

WordPress offers a more native way for Content Publisher content to coexist with existing content.

Key aspects of this approach:

• Content as WordPress posts/pages: When you publish from a Google Doc via Content Publisher, it gets published directly into the WordPress database as a post or a page.
• Seamless coexistence: Content from Google Docs (marked with an "Edit in Google Docs" link) sits naturally alongside content created directly within WordPress.
• Leveraging WordPress search: Because Content Publisher content is integrated into the WordPress database, it's automatically discoverable through standard WordPress search.
• Future Enhancements (Remote Entity Fields): While direct embedding of Google Docs within Gutenberg blocks is not yet fully native, there are ongoing projects in the WordPress ecosystem (like Automattic's remote data blocks) that could enable more flexible integration of Content Publisher content within existing WordPress content types and blocks.

Addressing Common Concerns

• Caching and instantaneity: Content Publisher is designed for near-zero lag time between publishing a Google Doc and its appearance on the live site. Any significant delay is considered a bug. Content Publisher triggers cache invalidation for updated content, ensuring freshness without clearing all caches.
• Governance and permissions: Content Publisher includes built-in publishing permissions, allowing for clear separation of responsibilities. For example, product managers can draft release notes in Google Docs, but a different role might be required to approve and publish them. This provides greater control than ad-hoc workflows involving GitHub pull requests for non-developers.
• Source of truth for technical documentation: Even for technical documentation typically managed in Markdown files within GitHub, Content Publisher can be advantageous. It can act as an ingest API to reduce static site generator build times from minutes to seconds, providing the "best of both worlds" by combining the power of code-based workflows for technical content with the speed of Content Publisher.

Conclusion

Whether you're launching a brand-new site with a modern front-end or enhancing an established Drupal or WordPress platform, Content Publisher offers a compelling solution to streamline content workflows.

By embracing the reality that much content originates in collaborative tools like Google Docs, it empowers creators, reduces operational overhead, and ultimately helps teams publish better, faster, and more reliably.

Want to go deeper? Watch the webinar on this topic, onmdemand now.

Ready to try it for yourself, on your site or in our playground environment? Start your free trial now.