This article is written for people writing for WordPress, and using the Divi Theme in particular, because those are the clients I’m working with at the time of writing. The basic principles apply to any other Content Management System (CMS), however.

This article advances the ideas in Writing for the Web and Headings.

The problem: how authors compose webpages

Many people don’t write blog posts and webpages directly in their CMS editor. It’s more likely that an author will write in Microsoft Word, Google Docs, or an equivalent word processing app, then copy-paste their finished text into a new post or page. This makes sense: word processing apps are much better for collaboration; other people can contribute to, edit, or comment on work in progress in ways that are difficult to replicate in a webpage editor.

However, this approach carries with it a pitfall so large that most Web authors aren’t even aware it’s an issue. But as Web content creators we really need to be conscious of it.

The pitfall is formatting

The details of how and why formatting code works isn’t important in this article. Suffice it to say that, if I highlight some text, change it’s font and colour, make it bigger, or bolder, that custom formatting is stored in some code invisibly wrapped around the text in question.

That’s all well and good in a Word document, but when I copy-paste my text into WordPress, that invisible formatting code is carried over with it, and it becomes a problem in four ways:

• Clunky code.
  Word processing apps are surprisingly and frustratingly erratic about inserting formatting code and, in worst case scenarios, can end up stuffing a soup of largely redundant, but invisible, text around your precious article. This is an issue because:
• It adds to page size.
  We really want to keep the size of a page as small as possible, and all the extra — even if its invisible — text can add significantly to download size. Google ranks pages partly based on how quick they are to load (especially for mobile), so it’s not a trivial issue. (This is partly why optimising image sizes is also important.)
• It conflicts with your theme.
  If you’ve invested time and money in a website layout, you don’t want to find external formatting compromising your look-and-feel. This is particularly true of headings: manual formatting will simply override your built in styles. Format as I suggest below, and the designed formatting will attach itself automatically.
• It compromises your SEO efforts.
  Google uses quality formatting code to help work out what the page is about, and assign it a page rank. Manual formatting makes that automated reading much less clear, and that can put a dent into your SEO potential.

Formatting code has to be there

This isn’t a tutorial on HTML — the language that defines a webpage — because that overcomplicates the issue. However, it is important you understand that HTML has to be there, that its quality matters, and you can get great quality without having to tinker with any code.

How to copy-paste text from a document to WordPress via Divi: a step by step guide

[ 1 ] This page building mechanism is distinctive to the Divi WordPress theme, as viewed from a typical Edit page. For seasoned WordPress users, note that Divi completely overrides the standard Gutenberg Block Editor. Divi users may well prefer the frontend Visual Builder: that’s entirely up to you, and everything I say below still applies.

[ 2 ] The four tools we’re going to heavily rely on in this tutorial. The pair of tabs on the right offer us two ways to look at our text. Don’t be deceived: even under the Visual tab what you see here is not necessarily what you’re going to see as a website visitor. Don’t be concerned when the font and font sizes don’t look how you expect them: follow these instructions and the magic will happen. To become a wizard, you just need to get to grips with the Styles dropdown and the Paste as text button.

[ 3 – 4 ] In screenshot 3, under the Visual tab, I’ve copy-pasted some text from a word processor app into the editor pane. Switch to the Text tab, and you can see the HTML (i.e. formatting code) that’s been copied over behind the scenes. The fact that we can barely see our article content for the redundant formatting code is a big red flag. This is why the Text tab is useful: if all you see is formatting code, that’s the problem we need to fix.

[ 5 – 6 ] This is where the Paste as plain text button comes in. It’s only available under the Visual tab. Click the button, then paste your text into the editor window. [ 7 ] Now switch to the Text tab, and there should be nothing but your article text: contrast that with [ 4 ] above.

Warning! To emphasise: this approach means that any and all links will need to be rebuilt manually. So probably best to save the creation of links for the next stage.

[ 8 ] Highlight a line that needs to be designated as a heading (or a subheading). Click the Styles dropdown, and select the appropriate heading style — probably a “Heading 2” or “Heading 3” option, depending on your article structure. You can check that the job’s a good ‘un under the Text tab: you should be able to see the same line neatly bracketed by <h2> or <h3> “tags”.

Don’t be tempted to adjust the result for font or font size, even if it looks wrong: what we see in [ 9 ] is fine for the editor pane, and the formatting will correct itself when viewed by a regular user.