How I Move Google Docs Into WordPress With ChatGPT

A finished article in Google Docs should not mean another round of formatting work in WordPress. I built a ChatGPT workflow that handles that handoff without handing over the decision to publish.

The Article Was Finished. The Transfer Wasn’t.

I started thinking about this article after a conversation on X about moving drafts into WordPress. It made me look at my own setup differently. I had already solved the part of the problem that kept getting in my way, and I had not needed another publishing subscription to do it.

The problem was never getting words from one box into another. Copy and paste can do that. The problem was getting a finished article into WordPress with the right structure, category, metadata, links, and ending, without rebuilding the same details every time.

On JimLunsford.com, different kinds of articles have different publishing requirements. A Recovery Standard is not laid out like a long technical article. The introduction link at the bottom changes with the content family. Sources belong in different places in different series.

Those are small things until I have to remember all of them again. I wanted the transfer to arrive with those decisions already applied, not leave me another cleanup job.

The Stack Is Smaller Than It Sounds

My authoring documents live in Google Docs. ChatGPT can read those documents through the connected Google Drive app. It also has access to my writing references and a separate publishing standard that explains how content belongs on my site.

WPVibe supplies the WordPress connection. It gives ChatGPT tools for working with the site rather than merely describing what I should click. WordPress remains the place where the draft is stored and the article eventually becomes public.

The useful path is simple: current Google Doc, publishing rules, ChatGPT, WPVibe, WordPress draft, verification. I initiate the handoff. This is not a background service watching every change I make in Docs and automatically pushing it onto the website.

I use ChatGPT during writing too. It helps me develop ideas, question weak sections, and work on drafts. That is a separate job from transferring an approved article. When I ask for the WordPress draft, I do not want the wording quietly improved on its way there.

This was not my first publishing workflow. I previously built draft handling and WordPress verification into Cypher, my private assistant. That earlier work taught me why the active version and the stored WordPress version have to agree. The setup described here does not require someone else to build Cypher first.

Connect the Tools Before Trusting the Workflow

Start with a WordPress site where you can install the required plugin, a Google account containing your drafts, and a ChatGPT account that exposes the needed integrations. My example is a self-hosted WordPress site using the block editor. I would not assume a restricted hosting plan or a page-builder layout behaves the same way.

For Drive, use OpenAI’s current Google Drive setup instructions. Find Google Drive in ChatGPT’s apps or plugins area, connect the Google account that actually holds the documents, review the requested permissions, and complete authorization. Availability can depend on the account and organizational policies.

Then test a real read. Give ChatGPT a harmless document’s exact URL and ask it to return the title and opening paragraph without changing anything. A connection badge is useful, but retrieving the intended document tells you more.

For WordPress, follow WPVibe’s ChatGPT connection guide. Its supported setup uses the WordPress-side plugin, a WPVibe account, and authorization for the site. Add or connect WPVibe in ChatGPT and complete the provider’s authorization flow. Do not paste your normal WordPress password into the conversation.

OpenAI documents how installed plugins are used in conversations, including selecting or mentioning them when needed. Make sure the current conversation can use both connections. Installing something elsewhere in an account is not a substitute for checking the tools available in the chat doing the work.

The first WordPress request should be a read, not a publication:

Use WPVibe to inspect your site. Confirm the site name, available post categories, and active SEO plugin. Do not create, update, or publish anything.

Read the result yourself. Check the domain. Someone with several sites should be especially unwilling to accept “connected” without knowing which site is connected.

I also treat these connections as access decisions. WPVibe’s privacy policy describes the content and connection data its service processes. OpenAI explains its handling of connected Google app data. This is not a local-only system. Understand the access before sending confidential drafts through it.

Write Down What a Finished Post Looks Like

Connecting the tools gave ChatGPT access. It did not tell ChatGPT what I consider a properly prepared article.

I built a document called JimLunsford.com WordPress Publishing Profiles and Draft Creation Standard. It records the content families, their categories, their body structures, the footer each one uses, and the checks required before calling the draft complete.

A publishing profile is just a written answer to a practical question: what does this type of post need on this site?

My Recovery Standards use continuous prose without H2 section headings. A regular long-form article normally has a short opening followed by H2-led sections. The profiles preserve those differences instead of letting the transfer turn every article into the same template.

The same applies to the ending. A Recovery Standard points new readers toward the Recovery Standards introduction. A project article points them toward Why I Build This Way. The three Read Next choices come from the approved document, not whatever related posts the model happens to remember.

Recovery Standard: No Permission or Praise made the problem clear. The article text had been transferred, but the draft was still missing pieces of the layout I use on the site. Getting the words across had not finished the job.

The correction put the More block after the opening paragraph, added the wide separators and the right New Here link, and made Read Next one real list instead of three unrelated paragraphs. Those were part of the post, not optional cleanup after the transfer.

I put that finished structure into the Recovery Standards profile. The next request could use the same instructions instead of leaving me to notice and explain the same missing pieces again.

On my site, the More block belongs immediately after the first paragraph. That establishes the teaser boundary my publishing setup uses. WordPress documents that the More block’s effect depends on the theme, so another site’s rules may need a manual excerpt instead. My preference is not a universal WordPress requirement.

I keep these rules available as project reference material. A new conversation should read the current standard rather than reconstruct it from old messages. This is related to what I learned about reusable project documentation: the useful part is having the right instructions available when the work starts, not assuming the model will remember everything.

Give the Article One Clear Source

A document named Final is useful only when it really is the version I approved. A newer backup or an old chat export can contain the same title without being the right source.

My normal instruction uses the article title because the working rules tell ChatGPT how to find the current authoring document. For someone’s first setup, I would use the exact Google Doc URL. It removes a source of ambiguity while the rest of the workflow is being tested.

The document also needs a clear boundary between public writing and private notes. Some of my Docs have an Article tab and a separate Publishing Details tab. The title, SEO description, proposed category, or drafting notes are not all supposed to become visible paragraphs in WordPress.

A source instruction should identify the article body, the metadata, and anything that must stay out. When two versions conflict or the approved version is unclear, the handoff should stop for clarification rather than choosing whichever file appeared first.

My Editorial Library serves a different job. It holds published-work snapshots flowing from WordPress into Drive for research and internal links. Those snapshots do not automatically write back to the site. The approved authoring Doc supplies a new draft; WordPress remains the authority for what is already public.

Build a Small Publishing Profile First

Nobody needs my entire set of site rules to start. Pick one ordinary article type, look at an existing post that is correctly formatted, and describe what should be repeated.

Before filling out a profile, give ChatGPT that post and ask it to inspect what is already there:

Use WPVibe to inspect [site URL] and this correctly formatted post: [post URL]. Propose a publishing profile based on its category, blocks, excerpt or More-block behavior, SEO description, and footer links. Identify the active SEO plugin and the field or tool it uses for descriptions. Separate what you verified from anything I need to decide. Do not create or change anything.

Check the proposal against the post you chose. Decide which details should repeat and which belong only to that example. If the SEO field is still unverified, leave it unresolved and confirm that it saves correctly during your first-draft test.

Use this starter profile to record those decisions. Replace the bracketed fields before the first transfer.

Target: Work only on [site URL]. Use [article type] and the existing category [category name]. Confirm the category on the site. Do not create a new category.
Source: Read the current approved document at [Google Doc URL]. The public body is [tab or clearly marked section]. Metadata and private notes stay outside the body.
Transfer: Preserve the approved wording, paragraph order, headings, emphasis, and link destinations. Create native block-editor content, not one large Custom HTML block. Put the title in the WordPress title field only.
Site choices: Use [More-block or excerpt rule], [verified SEO plugin and supported metadata field], and [footer structure with exact links]. Do not invent missing values, add images, or add tags.
Existing content: Use [intended slug] for this article. Check the title and slug before creating anything. If a matching draft or published post exists, report it and ask before changing it. Do not blindly repeat an uncertain write.
Finish: Create a draft only. Read it back and compare the body and metadata with the source. Report the post ID, status, category, checks completed, and anything unresolved. Do not publish, schedule, or change site settings.

Attach that profile to the conversation or make it available in the project’s reference files. Then explicitly ask ChatGPT to read it before the first handoff. Saving a document somewhere does not prove the conversation used it.

You may discover that you have never decided what belongs in your excerpt or which links should close an article. Make that decision once, then put it in the profile.

What My Short Request Actually Sets in Motion

Now I can give it a request like this:

Find Recovery Standard: Power Through Restraint on my Google Drive and create a draft on JimLunsford.com.

The sentence is short because the publishing rules carry the detail.

ChatGPT reads the current authoring Doc and the matching profile, then checks WordPress for an existing post by title and slug. A match gets reported before anything is created or changed.

It separates the article from its publishing notes, builds native WordPress blocks, and adds the footer defined by the profile. The approved wording, formatting, and links stay intact.

It looks up the category on my site rather than assuming a number from another installation means the same thing.

SEO metadata needs the same care. My site uses The SEO Framework, and my verified description field is _genesis_description. The field named wpai_meta_description is not a substitute in my setup. Saving text in a field with a plausible name does not mean the active SEO plugin uses it.

The profile names the active plugin and its description field, and the saved value gets read back. Another plugin needs its own verified field or tool. If the connection cannot save the description correctly, that part stays unfinished.

WPVibe provides the site operations that carry this out. I did not build that connector. I built the site-specific instructions around it and required the resulting draft to match them.

This publishing handoff also does not require the separate command-chat and Work-chat arrangement I use for serious software development. The scope here is smaller: prepare one article correctly in a conversation with the necessary files and tools.

The Readback Is Part of the Job

Getting a post ID back does not mean the handoff is finished.

My publishing standard requires reading the WordPress draft back. The checks cover the title, slug, draft status, category, opening, More block, paragraph order, headings, links, end matter, and SEO description. The metadata should not have leaked into the visible body, and the title should not appear twice.

I want the completion report to distinguish a verified result from an assumption. “The description was saved and read back correctly” says something specific. “Everything looks good” can hide a surprising amount of unfinished work.

Stored-content verification and visual inspection are different checks. I still want to open the draft in the editor and preview it, particularly when a profile is new or the theme has changed. A correct block structure does not by itself prove that every screen size looks right.

Failures need a defined response too. If the source cannot be read completely, stop before creating an incomplete article. If an operation times out after a possible write, inspect WordPress before trying again. If a metadata check fails after the draft exists, report the existing post ID and the unfinished field instead of starting over with another post.

The Cost Is Not Another Publishing Subscription

I already pay for WordPress hosting, a domain, and ChatGPT. Building the setup took time. What I did not add was a separate publishing-automation subscription.

My connected WPVibe account is on its free plan. When I checked the published pricing on October 2, 2026, that plan listed 100 WordPress tool calls in a rolling 24-hour window, all tools and skills, and unlimited connected sites. That allowance is per account, not per website.

One hundred calls does not mean one hundred articles. Reading the site, creating a draft, handling metadata, and verifying the result can require several operations. A heavier workflow may need a paid tier. ChatGPT also has its own limits.

For someone already paying for ChatGPT Plus or Pro, with the required integrations available, this may fit inside tools they already have.

What about ChatGPT Free? WPVibe’s connection guide says its app works with Free. That does not establish that every Free account can reproduce this complete workflow with the same Google Drive access.

OpenAI’s Library documentation lists plan requirements for Drive in Library. I have not verified the full handoff on ChatGPT Free. Test both connections in your own account.

Check the current pricing and test whether the allowances fit your work. Paying for a packaged service may be worth it for the support or convenience. I did not need one for this handoff.

Test One Draft Before You Trust Ten

For a first run, use a throwaway article on a staging site when one is available. Give it a unique title, a short opening, a couple of paragraphs, a heading, one internal link, one external link, and an SEO description. Use content you can compare without spending twenty minutes reading it.

Ask for a draft, then check the actual result in WordPress. Look at the status, category, link destinations, block structure, metadata field, and preview. A useful test includes the awkward details you expect the workflow to preserve, not just three plain sentences.

Next, ask the system to check whether that same article already exists. It should find the draft, not manufacture a second copy. Revise one sentence in the source, explicitly authorize updating that same draft, and verify that the intended post changed without unrelated rewriting.

Images, galleries, page-builder content, custom fields, and complex embeds deserve their own checks. A picture visible in Google Docs is not proof that it was uploaded into the WordPress Media Library with the correct details.

Check what the connection can actually do. My own WordPress connection has administrator capabilities, including publication. “Draft only” is a rule I impose on the task, not a technical guarantee that the connection cannot publish. ChatGPT’s app permission controls can govern confirmations, but those settings should not be confused with the permissions of the connected WordPress account.

Use the access you understand, keep backups, and refuse unrelated changes. Preparing an article is not permission to install a different theme, change plugins, or rewrite the site’s settings.

When the first profile works, add another content family. When the site changes, update the affected rule and test it again. There is no prize for turning a small, useful handoff into a giant system before it needs to be one.

I Wanted the Repetitive Work Out of the Way

I already knew what my posts should look like. Writing those decisions down gave ChatGPT something specific to follow, and checking the result showed me what still needed fixing.

Now I can finish a piece in Google Docs, request the draft, and open WordPress to inspect it instead of rebuilding the same layout. I still decide what gets published. I just do not need to do the same preparation by hand every time.

New Here?

Start Here: Why I Build This Way