WP to Static

A Static HTML website would show errors if you saved your dynamically generated WordPress website as it is using httrack or other utilities. So first make sure that useless dynamic content which might lead to errors in HTML is disabled.

Httrack will download your website and try to maintain the same structure as it crawls. For example if you used permalinks like example.com/2011/10/post-name/ then your post will be saved in 2011/10/post-name/index.html so you need to think what kind of HTML structure you want for the static website and configure it before running httrack.

1. Turn off comments on your blog using the plugin http://wordpress.org/extend/plugins/disable-comments/

Why you need to do that? is because if your HTML pages had comment form it will not work because there will be no php behind it to process it.

2. Disable plugins and widgets that generate dynamic content on your website. Such as recent posts, related posts, recent comments, search, calendar, Archives drop down menu, etc.

3. Use httrack https://www.httrack.com/ to download your entire website.

We recommend:
OSX (MacPorts) package
OSX (Homebrew) package MacPorts Package – sudo port install httrack
Homebrew Package – brew install httrack

Do whatever you want with your static website, you can upload it to a webserver but make sure you check it throughly for broken links. Or you can archive it on your hard disk.


It is possible to make a static website from WordPress. Here is a short guide for that:

Before you start:

Change all dynamic content on the website to the external services, f.e.:
comment to Facebook Comments
contact form to Formspree
search to WP Google Search
Change permission to access to the WordPress in .htaccess because WordPress is only a content “donor”.
Preparing environment

Install WordPress plugin to grab HTML data: Simply Static
Configuration:
Use absolute URL
set Static type
set localisation to Local Directory
Generating static page
This could take few minutes

Testing
If some pages wasn’t generated you can add them in Additional URL field

https://www.lambrospetrou.com/articles/wordpress-backup-static-hosting/

A few months ago I started migrating all my projects and websites into AWS. The last thing standing was my old wordpress blog (hosted at mastergenius.net, not alive anymore). Today, I decided to make a final backup and create a static version out of it and ditch the VPS I have running just for that.

It turned out to be extremely easy 🙂

Backup all content

Apart from serving the content as static website I wanted to have the posts in a form that can be easily imported later back in Wordpress and also a format which is easy to parse and read using a text editor.

I just wanted the text, which is the heart of any article anyway, so I just did the usual export feature of Wordpress as described in the official export documentation.

A full folder copy is recommended too, you know just in case I want to revisit any files, images or code!

Serve as static website

There are a lot of ways to dump an active wordpress installation and several plugins that allow you to do this conversion easily. I just took the simplest way and used the well-known wget Linux command line tool (original Quora question link with the command is in the References section).

wget -k -K  -E -r -l 10 -p -N -F --restrict-file-names=windows -nH http://active-wordpress.domain.com

After executing the above command I deleted all the unnecessary files, stripping down the whole site in some MBs.

I just uploaded the static files to Amazon Simple Storage Service – S3 and that’s all!

Zero-cost hosting 🙂

References

WordPress is a great platform for building websites, especially with the help of a visual editor such as Elementor. It has extensive documentation and a big community, you can create an eCommerce with WooCommerce, forums with bbPres, etc, infinite possibilities a plugin of distance.

Speed a WordPress installation is also not a tricky job, nowadays most cache plugins are able to handle the majority of the performance aspects and there are thousands of managed hosting providers. I still use WordPress for a few side projects I run and there is no doubt it is the right solution for a lot of people, despite of all the hate it receives from part of the development community due to its monolith nature, lack of proper boundary between extensions or because it’s coded in PHP.

Personally I don’t hold any grudge for a specific technology, they will be replaced naturally by better alternatives in their own time, for reasons that the market deems right, today’s blu ray is yesterday’s tape. WordPress is still the go-to solution for most website development agencies and may continue to be for years to come.

As a security guy, I try to keep things simple as possible. WordPress is an all-in-one solution and it has much more features than I require for my personal blog. It’s somehow overkill for what I needed and you gotta have at least locally, a webserver with a database in order to use it.

Previously I used a docker container to run my website locally and used

Northon Torga
Northon Torga

Northon Torga

Security Analyst III @sucurisecurity. CTO @goinfinitenet. Qapla’!


https://wordpress.org/plugins/static-html-output-plugin/

Converting a WordPress site from dynamic to static pages is one way of improving speed and reduce security threats. In this article, we will see why and when it is necessary to convert the WP site to a static one, the common methods, and a step by step procedure.

WordPress is a popular content management system that is easy to set up and run by both technical and non-technical people. However, it utilizes a database system and other dynamic website components that can potentially slow down the page load times, or expose it to security vulnerabilities.

You may, therefore, consider converting your WP site to HTML based website if you want to improve speed and security. A static website does not execute database queries, PHP code, and other tasks that take longer and slow page load times. Instead, it loads the HTML pages almost instantly when a user makes a request.

There are several different methods of converting WordPress websites to HTML. You can use a WordPress plugin, such as Simply Static, or a third party desktop tool such as HTTrack.

The basic process involves converting every post and page into a static HTML article. Each of the conversion methods generates HTML files and directories that follow a similar structure as the WordPress website. You can then upload the html files, in the same structure, to a subdomain or the primary domain, and continue accessing it as if it was the original WP website.

Using a WordPress Plugins

WordPress plugins such as the Simply Static and others have the ability to automatically convert each of the WordPress pages and posts into static HTML files.

Using the Simply Static plugin to convert WP to static HTML

  • Login to your WP dashboard
  • Locate and open Add New under the Plugins
  • Type and search for Simply Static in the keyword search field
  • Install and activate the Simply Static plugin

Click Settings to configure how you want to convert the files.

This will give you a screen with three different options for the destination URLs, and a choice of the delivery method.

Choose Destination URL Options available

Use Absolute URLs

You can convert and create HTML files that will work on a different URL or domain. In this case, use the first option and add the URL where you intend to place the static website.

Specify the destination URL where to place the resulting HTML content. This could be a subdomain, directory, or in some situations the main domain URL.

If you want to replace the WordPress on the main domain, use its URL. But note that this will replace your WordPress files and you may need to move them to a different directory.

Relative URLs

This converts you WP website to static HTML files that can work in any website regardless of the name. It gives you an option to include a path, just in case you do not want to put them on the root directory.

Save for offline use

This allows you to convert WP to static URLs that you can save on your local drive or another storage medium. This option will enable you to browse the website offline.

In all the options, you need to specify the delivery method.

Choose delivery method

After you have selected the Destination, go to the Delivery Method and use the drop-down list to choose either a Zip archive or a Local Directory.

Click Save Changes

Generate HTML files

Navigate to the Simply Static section and click Generate. Click Generate Static Files in the window that opens. The conversion process begins and this will take a few minutes or more depending on the size and complexity of the WordPress website.

Once complete, it displays a link of the downloadable, compressed file which you can save locally and extract to the URL where you want to use it, or a local if you want to browse offline.

  • Click on the link provided to download the file to a local drive.
  • Login to cPanel and open the legacy File Manager, you can also use an FTP client. Go to the folder for the URL where you want to load the HTML website.
  • Click Upload

  • Locate the compressed file to upload from your hard drive.
  • Select and upload it to the URL.
  • The process takes some minutes depending on the speed of your internet connection
  • Go to the URL where you have uploaded the file
  • Highlight the file and click Extract to decompress the files. You can also right-click on the file and choose Extract.

Choose the same directory where you want your website. In our case, we use the /testing/ directory in the example.com folder. If you want it in the root domain directory, do so, but ensure that your previous WordPress files, if using the same directory, are in a different location to avoid overwriting them.

Your static website version is now ready to run. If you type its URL at the browser, it should open just like your WordPress site.

Confirm that all links are working.

Using HTTrack to convert WordPress to a static website

HTTrack is an open source tool that downloads an entire website onto a local storage while retaining its structure. As it downloads the files, it creates directories, images and HTML, and other website files, as well as a structure that enables users to browse the website offline.

The mirror site on the local drive has a link structure similar to the original site. The tool is customizable and has the ability to perform updates to keep the offline site the same as the live version.

How to use HTTrack

  • Download the open source tool from http://www.httrack.com/page/2/en/index.HTML  Choose the version compatible with your operating system.
  • Install and launch the application from your computer
  • Give it a name to differentiate it from other websites that you may download in future
  • Choose the Download web site(s) in the Action drop-down list.
  • Enter the URL for the WordPress you want to download in the Web Address (URL) box, you can specify more websites by clicking the Add URL option.
  • Click Next and then Finish starting the conversion and downloading process.

    The HTTrack local site will follow the WP’s permalink structure. It also saves most of the dynamically generated content such as recent posts, comments, related posts and others as HTML.
  • Once the process is complete, you can upload the entire website on a domain or subdomain as well access it offline from your local machine.

Since it saves all the individual files separately, use a compression tool to put the files into one ZIP or RAR file that is easier to download to the website. Use the legacy file manager, or an FTP client, to upload the zipped file in the URL where you want your HTML website. After uploading the file, extract the files in your preferred directory/URL.

Conclusion

The ability to generate HTML website files for you WP website is something you may need to consider if you want to increase the speed and security of your website.

Converting the WordPress website removes the dynamic functions such as comments, contact forms, e-commerce and others that rely on PHP.

As such, you may consider third-party tools such as Discuss or Facebook for comments, as well as other third-party solutions to perform the dynamic functions a static website does not provide.

 

Check out these top 3 WordPress hosting services:

or click to check out the full list of top WordPress hosting companies

Was this article helpful?


How to Generate a Static HTML Copy of Your WordPress Website

You can create almost any type of website you want using WordPress. However, you can’t use it to build simple static HTML websites. In some cases, that’s all you need, and you may end up needing to use another platform to achieve it.

Fortunately, there’s very little you can’t do with WordPress plugins. In this article, we’ll talk about when it makes sense to use simple static WordPress pages. We’ll also introduce you to a plugin that enables you to generate static WordPress pages and discuss how to host them.

Let’s go!

Why You Might Want to Use a Simple Static Website

Before we dive any further, let’s talk about what static pages are. We say a page is ‘static’ when it doesn’t load any dynamic content and it’s made up of only HTML, CSS, and potentially some JavaScript. In a lot of cases, people associate static pages with overly simple designs, but you can do a lot just with HTML and CSS.

WordPress, in contrast, only generates dynamic pages, no matter how simple your designs are. For example, by default your latest posts are featured on your homepage. To achieve this, it uses something called the WordPress ‘loop’. The loop looks for the latest posts you published and lists them in chronological order:

The WordPress loop in action.
The WordPress loop in action.

The fact that WordPress only generates dynamic pages isn’t a downside. Far from it, as it enables you to create almost any type of site you want, from simple to complex projects. However, there are cases when you might want to use simple static pages instead. For example:

  • It can be better for security purposes. With static pages, your server doesn’t need to ‘render’ your site each time someone visits it. Instead, it just sends them simple HTML and CSS, so it’s harder to exploit your website.
  • Static pages tend to be faster. Static pages generally load faster since your server doesn’t need to generate them on the fly.
  • They’re less prone to errors. WordPress is very user-friendly, but errors can still occur. With static pages, most of these, such as database connection errors, won’t be a problem.

While static pages have clear benefits, it’s no coincidence the web is steadily moving towards more and more sites using Content Management Systems (CMS) instead of building pages from scratch. This is because dynamic pages enable you to implement many more advanced features.

Let’s look at a quick example. With a static blog, you’d need to update your homepage every time you create a post. That means adding a new blurb, featured image, and more for every single update. WordPress, on the other hand, does all that heavy lifting in the background thanks to the loop.

However, if you want to set up a website you won’t need to update often, static pages will work great. Likewise, sites with very simple functionality, such as small portfolios or online archives, might be better off with a static approach.

The downside is you usually wouldn’t be able to use WordPress to create those sites. With Divi, it might take you only a few hours to set up a professional looking website with a couple of pages. However, they wouldn’t be static. Fortunately, there’s a plugin that can help.

Introducing the WP Static HTML Output Plugin

The WP Static HTML Output plugin.
The WP Static HTML Output plugin.

The WP Static HTML Output plugin has been around for a while, and for good reason. This plugin enables you to generate fully static copies of your entire WordPress website and to deploy them to other platforms.

On top of transforming your WordPress pages into static copies, the plugin can also replace all its internal links. In practice, this enables you to use WordPress to create your website in a local test environment, and then deploy it on your hosting platform of choice.

WP Static HTML Output also packs all your media files when you export your website. You can also use it to store a past copy of your site as a backup.

However, keep in mind it’ll run into trouble if you try to use it to replicate dynamic features, such as comments sections, log-in forms, and more. Generally speaking, if there’s functionality on your site that requires user input or could be considered dynamic, it won’t work when you translate it into a static page, so bear that in mind while considering whether to use the plugin.

Key Features:

  • Create fully static copies of your entire WordPress website.
  • Export your content alongside all your media files.
  • Replace all your internal links so you can deploy your static WordPress pages to a live environment.
  • Store copies of past exports as backups.
  • Rewrite the paths for your WordPress content to hide the fact your website uses the platform.

Price: Free, with a premium version available | More Information

How to Generate a Static HTML Copy of Your WordPress Website (And Host It Using GitHub)

In this section, we’re going to show you how to deploy your static WordPress pages to GitHub. GitHub enables you to host static pages for free, which makes it a decent option if you want to use it as a no-frills host for static pages.

Step #1: Generate a Static HTML Copy of Your Site

For this step, we’re going to use the WP Static HTML Output plugin that we introduced earlier. Go ahead and install and activate it on your website now. Once that’s done, go to the Tools > WP Static HTML Output tab on your site.

Before you generate a static copy of your site, let’s go over a few settings the plugin offers. First off, you’ll see an option to state the URL you intend to use for your site once it goes live. Keep in mind, your static pages won’t display properly unless you enter the correct URL here since your pages won’t be able to pull the CSS they require to look pretty:

Setting the URL for your static website.
Setting the URL for your static website.

This setting will take all your internal links and replace them with the URL you set. Earlier, we talked about how you can use this feature to create sites locally and deploy them in a live environment. As such, you might want to check out our tips on how to choose the perfect domain name.

Moving on, you can enable settings to export your website as a zip file, which you can download from your dashboard. Otherwise, the plugin will just export your new files to the wp-content/uploads/ directory. Here you can see that directory with a couple of full exports of our site. You can also choose whether you want to retain the last export you create, to use as a backup:

Configuring your site's export settings.
Configuring your site’s export settings.

If you want to change the folder to which the plugin exports your pages, you can do so under the Override Output Directory section:

Overriding your export's output directory.
Overriding your export’s output directory.

Finally, there are options to replace your default WordPress paths with names of your choosing. The idea is to obscure the fact your site was built with WordPress:

Obscuring your WordPress settings.
Obscuring your WordPress settings.

Whether to use this feature is up to you since it won’t affect your exported page’s functionality in any way. Once you’re ready to create static copies of your WordPress pages, click on the Start static site export button:

Starting to export your static website.
Starting to export your static website.

The plugin will do its thing now and you can track its progress through the Export Log at the bottom of the tab:

Your export log.
Your export log.

Once the process is finished, you should see a line within the Export Log near the very top that says ZIP CREATED including a link to its right:

Downloading your static website as a ZIP file.
Downloading your static website as a ZIP file.

If you copy and paste that link on your navigation bar, you’ll be able to download a static copy of your website directly, so you don’t have to use FTP. Once you have your static site, it’s time to test and publish it.

Step #2: Upload Your Static Website to GitHub

At this point, you should have all the static files created from your WordPress website. It’s now time to find somewhere to host them, so you can check if they’re working as intended.

Let’s do this using GitHub, which enables you to set up simple static pages through repositories. If you haven’t used GitHub before, or need a reminder, here’s a quick guide to get you started with the platform.

Once you’ve set up a GitHub account, you’ll need to create a new repository. Type a description if you want to and leave your repository set to Public, then click the Create repository button:

Creating a new repository.
Creating a new repository.

Once your repository is ready, you need to upload your WordPress files to it. For this, you can use the command line if you’re familiar with git version control or use GitHub’s desktop app. We’ll use the desktop approach here since it’s easier to follow along.

When you set up GitHub desktop’s app, you’ll be able to clone existing repositories from your account:

Adding a new repository to the GitHub app.
Adding a new repository to the GitHub app.

Choose the repository you set up earlier from the list and set its Local path to any folder you want. You’re going to use that folder to add your WordPress files, so make sure it’s somewhere you can remember:

Configuring your repository's local folder.
Configuring your repository’s local folder.

Unzip your exported file from step number one and extract its contents to the local repository folder you set up a second ago. Once you do that, the GitHub desktop app will detect the changes to the repository. Specify a name for your first commit and then click the Commit to master button:

Committing your changes to the repository.
Committing your changes to the repository.

Now, when you click the Publish button at the top of the app your changes will be uploaded to GitHub.

You’re almost ready to access your page now. However, first we need to configure GitHub to recognize your repository as a website. To do that, go into your repository settings and look for the GitHub Pages section. Under Source choose the master branch option and click save:

Checking the source for your GitHub page.
Checking the source for your GitHub page.

Your site’s URL will now show up at the top of the section. If you visit it, you should see your WordPress website show up, only as a static page:

An example of a WordPress static page.
An example of a WordPress static page.

As we mentioned earlier, some parts of your website might not work if they rely on dynamic content, such as comment sections. However, if this is the case, you would likely have any use for static pages anyway and should stick to use WordPress as normal.

Conclusion

In some cases, simple HTML and a little CSS is all you need to build an informative and elegant website. However, WordPress generates dynamic pages out of the box. That’s far from a bad thing, but it does mean you need to do a little tinkering if you want to create static WordPress pages.

Here’s how to get the job done and publish your static pages for free, in three steps:

  1. Use the WP Static HTML Output plugin to create a static copy of your site.
  2. Upload your static pages to GitHub.

Do you have any questions about creating static WordPress pages? Let’s talk about them in the comments section below!

Article image thumbnail by Andrew Rybalko / shutterstock.com



https://www.brianshim.com/webtricks/wordpress-static-site-generator/

WordPress is a great website platform which I use and develop on every day, but, it has its weaknesses. It requires a database that is accessed dozens (or hundreds?) of times every time a page is loaded, which can slow down page load times. It’s kind of a wasteful use of server resources if your content doesn’t change very much. And it can have security issues.




What if you could use WordPress, but have all of the advantages of a static HTML site? The solution I’m talking about is to set up a staging WordPress install and render the pages out as static HTML files to the live production site using the Simply Static WordPress plugin.

I tried this with a few of my blogs and I’ll walk you through the process!

The Big Caveat

Before I go any further, I want to be clear about the big limitation of rendering your WordPress site to HTML. Namely, you will lose all server-side functionality! Here’s a partial list of stuff that won’t work on your static WordPress files:

  • server-based comment forms
  • server-based contact forms
  • almost any plugin that uses a submit form
  • “most popular posts” widget
  • site search
  • events signup plugins
  • e-commerce plugins
  • membership plugins
  • RSS feed (unless you find a workaround or write some code.. anyone who knows an easy solution please comment!)
  • and many other plugins that require dynamic server functionality!

Obviously, this eliminates a lot of types of websites from being able to use this solution!

But there are workarounds. Some of server-based features not available to static sites can be achieved with client-side solutions. For example, you can implement commenting using Disqus (or other client-side commenting services) instead of using the native WordPress commenting system.

Types of Sites Which Are Ideal for this Solution

Here are some types of websites which might be ideal for static site generation:

  • Purely informational sites
  • Online corporate brochures
  • Landing pages or “Coming Soon” pages
  • Blogs (using client-side commenting)
  • Sites that need to load really fast
  • Sites that need exceptional security, or that will be especially targeted by hackers (i.e., political sites, celebrity sites, etc.)

Basically, if your site is purely informational or purely informational with client-side comments, the rendered static site should work fine.





Benefits

There are some really huge benefits of serving static HTML files to your visitors instead of a database-driven site.

1. Insanely Faster Load Time

The load time speedup you can get is really insane. In my experiments, my WordPress site’s average load time was 4-6 seconds; not bad. When I rendered it to HTML, the load time went down to under a second! And this was on cheap shared hosting!

Your WordPress theme might make dozens or even over a hundred database calls to render your site. All of that activity takes time and results in slower load time. Caching plugins help, but do not completely eliminate all database calls, or the fact that PHP has to execute on the server. Static HTML files have none of that.

2. Improved Site Reliability

If you’ve worked with WordPress sites for a while, you’ve undoubtedly seen the dreaded “Unable to connect to database” error that occurs when your database server goes down. When that happens, your WordPress site goes down too.

Static HTML sites don’t have this source of unreliability. I’ve noticed that more than half of the time when my WordPress-based sites are down, my pure HTML sites still work! Reliability of static sites is more than twice that of database-driven sites, in my experience.

Now, with the static WordPress solution, your source site will still use a database, so you won’t be able to edit if your database server goes down. But, at least your live site will still be up!

3. Lower Server Load

Since your static site is so easy to render compared to a database-driven site, it will have a much lower server load. This means you can use cheaper hosting with less memory and CPU power. I’m using low-cost GoDaddy shared hosting and getting under 1-second load times with my static WordPress-rendered site.

4. Way Better Security

SQL injection is one of the biggest security vulnerabilities out there. Static sites don’t have this vulnerability because there is no exposed database to hack. There is also no PHP code running. There are no exposed plugins to hack!

Of course, your staging WordPress site still has all of the disadvantages of needing a database. But, at least you won’t be exposing those limitations to the whole world, and you can take extra measures to hide your source WordPress site, such as hiding it behind an .htaccess password. For ultimate security, you can have your source WordPress install on your local computer (but this eliminates the convenience of the one-click deployment, just FYI).

5. Free Staging Server

Rendering out your WordPress site and only displaying the rendered static files to the public gives you this bonus feature: a free staging server! In other words, you can play with your WordPress site without affecting the public-facing site. If you hose your WordPress site, your static site will still be faithfully working. Publish your site only when it’s completely ready for prime time.

6. Easy Deployment to Different URLs

Moving WordPress from one URL to another is a pain if you have to do it often. Maybe your website is for an annual event that has the current year in the URL. The Simply Static plugin allows you to deploy your site to different URLs with just a few settings and clicks!

How to Do It

If I’ve convinced you, here’s how turn your existing WordPress site into a static site.

1. Copy Your Live WordPress Site

First, you’ll have to make a copy of your production WordPress site to its new staging location. This can be either offline on your local computer, or in the cloud on the same web server as your live site. There are pros and cons to each.

If you have your WordPress install to your local computer, you can work on it with no Internet connection, which is kind of cool. And, your WordPress install will be safe from hackers. But, you’ll need to set up a localhost (WAMP, MAMP, XAMPP, etc.). And, probably the biggest caveat is that it will take a bit more effort to push the rendered files to the server. You might need to use Filezilla to drag the files up manually (I’m sure there is a better solution out there though).

If you have your WordPress install on the same server as your live site, pushing the rendered files is a one-click affair using the “Simply Static” plugin that I use. This is really great, and makes the process almost effortless.

I like to use the Duplicator plugin to copy sites. But, there are many other plugins available for copying WordPress sites.

2. Install Simply Static

When you’ve set up your WordPress staging site, install the Simply Static plugin. This wonderful plugin renders your entire WordPress site to HTML files. At the same time, it replaces the base URLs in the WordPress database with the URL of your destination. Really cool!!

Note, there is another free WordPress-to-static generator plugin called WP2Static. There are things I like about that plugin, but in the end I chose Simply Static because it generates files much quicker.

From here on out, I’m going to assume that you’ve put your staging WordPress site in a subdirectory of your live site. For example, you could put your WordPress site in “/wordpress”. We’ll hide it later.

Another note: I did all of these steps successfully on GoDaddy hosting, as well as localhost. But, I wasn’t able to get either Simply Static or WP2Static to work on SiteGround hosting. If I find a fix, I’ll add it to this article.

3. Set up Simply Static and Generate a Test Site

  • Go to Simply Static -> Settings in your WordPress admin.
  • In the Destination URLs section, select “Use absolute URLs”. Note that you should select absolute URL paths or else the meta tags in the head will be relative, which is not good.
  • Enter the URL of a subdirectory of your main site for now, i.e., “http://yoursite.com/test”.  Remember to delete this directory after after your testing is done.
  • For Delivery Method, select “Local Directory”.
  • In the Local Directory field, complete the path to your local directory.

Go to Simply Static -> Generate and press the big blue button. Generation launch will take a few minutes. Thoroughly test the newly generated site at “yoursite.com/test”.

4. Add Missing Pages

In my case, I had some pages that were in the WordPress site but not in the static version. That was because there were no absolute links to those pages in my site, so the Simply Static plugin couldn’t find them. Simply Static won’t find pages linked by relative URLs.

Fortunately, it’s easy to add these pages manually by entering the URLs into the Simply Static plugin at Simply Static -> Settings -> Include/Exclude.  Add the URLs of the missing pages to the “Additional URLs” tab.

Or, you can go back into your WordPress site and change any relative links to absolute links. Be sure to use the URL of your WordPress staging site, not the production URL.

Regenerate the site to see if the pages appeared, and repeat if necessary.

5. Add Your Sitemap

I use the Yoast SEO plugin to generate site maps for my WordPress site. Site maps are used by search engines to help crawl your site. While not absolutely necessary, a site map is recommended for good SEO.

You’ll have to add the URLs of your sitemap pages to the “Additional URLs” section of the Simply Static settings page.  See the Yoast plugin for more information on where your site map is located. Here are some examples:

http://yoursite.com/wordpress/sitemap_index.xml
http://yoursite.com/wordpress/page-sitemap.xml

After the site is launched, confirm they appear in the production site and enter the URLs of your site map files into Google Webmaster Tools if you haven’t done so previously. They should be the same as they were before you went static.

6. Set Up Your 404 Page

Regular WordPress will provide a 404 “not found” page when a user tries to access a page or post that doesn’t exist. When you render your site to HTML, you lose that feature. But, it’s not hard to set up. You’ll need FTP access to our server. Here are the steps to do it.

  1. Create a 404 “not found” page in WordPress. Take note of the slug.
  2. Next, you’ll have to tell the Simply Static plugin to render this page, because there are no links to it. Log into the WordPress admin and go to Simply Static -> Settings -> Include/Exclude -> Additional URLs and add the staging URL of your 404 page.
  3. Re-generate your static files and push them to production.
  4. FTP to your server and go to your production site’s root.
  5. Add this line to your .htaccess file:
    ErrorDocument 404 /404-page-slug/
    where the text between the slashes is the slug of your 404 page.

Test by typing in a nonexistent URL on your production site. Your 404 page should come up!

7. Set Up Your robots.txt File

If you’ve set up your 404 page and modified your .htaccess file per the previous step, you technically don’t need to do this, but if you haven’t, you MUST do this step or else Google won’t index your site!  (Google’s crawlers will try to find robots.txt and will get an Internal Server Error).  Just create a blank robots.txt file your root and you’ll be good.

8. Hide Your WordPress Site

If your staging WordPress site is in a subdirectory on your live server, it will still be visible to the world, so you’ll need to hide it.

The first thing I tried was installing an “Under Construction” plugin to hide my WordPress site. Then, I rendered out my site and it consisted of one page – the Under Construction page! Haha.

So, the next thing I did was to protect my staging install with HTTP Basic Authentication. It turns out that the makers of the Simply Static were thinking the same thing. They built in support for Basic Authentication right into the plugin!

Setting up Basic Authentication will require you to FTP to your server and set up an .htpasswd file in your root directory. Google for instructions on how to do that. Here’s a site which generates your password hash.

Once set up, go to Simply Static -> Settings -> Advanced, and enter your username and password at the HTTP Basic Authentication section.

Note that if you’re concerned about security you should have SSL set up for your staging site as well.

9. Delete Test Directory

Finally, remove your test directory and any other temporary directories or files that you created.

10. Launch Your Site

When all of your pages are rendering properly to static HTML, you can move your old production WordPress files from the root to a temporary subdirectory, then try pushing your staging WordPress files to your site’s root directory.

First change the destination URL to your site’s root in the Simply Static settings.

Then go to Simply Static -> Generate and press the big blue button to launch your site to production!

You’re Done!

Voila! You should now have a static site derived from WordPress! Load time should be lighting fast!

Any time you need to update your site, just update your WordPress site like you normally would. When you’re ready to publish, just click the “Generate Static Files” button!

Any questions? How did it go for you? Let me know your thoughts below. – Brian


https://www.smashingmagazine.com/2020/02/headless-wordpress-site-jamstack/

How To Create A Headless WordPress Site On The JAMstack

In this post, we’ll set up a demo site and tutorial for headless WordPress, including a starter template! We’ll use the WordPress dashboard for rich content editing, while migrating the front-end architecture to the JAMstack to benefit from better security, performance, and reliability. We’ll do this by setting up a Vue application with Nuxt, pulling in the posts from our application via the WordPress API.

In the first article of this series, we walked through Smashing Magazine’s journey from WordPress to the JAMstack. We covered the reasons for the change, the benefits that came with it, and hurdles that were encountered along the way.

Like any large engineering project, the team came out the other end knowing more about the spectrum of successes and failures within the project. In this post, we’ll set up a demo site and tutorial for what our current recommendations would be for a WordPress project at scale: retaining a WordPress dashboard for rich content editing, while migrating the Front End Architecture to the JAMstack to benefit from better security, performance, and reliability.

We’ll do this by setting up a Vue application with Nuxt, and use WordPress in a headless manner — pulling in the posts from our application via the WordPress API. The demo is here, and the open-source repo is here.

If you wish to skip all the steps below, we’ve prepared a template for you. You can hit the deploy button below and modify it to your needs.

What follows is a comprehensive tutorial of how we set this all up. Let’s dig in!

Enter The WordPress REST API

One of the most interesting features of WordPress is that it includes an API right out of the box. It’s been around since late 2016 when it shipped in WordPress 4.7 and with it came opportunities to use WordPress new ways. What sort of ways? Well, the one we’re most interested in covering today is how it allows for the separation of the WordPress content and the Front End. Where building a WordPress theme in PHP was once the only way to develop an interface for a WordPress-powered site, the REST API ushered in a new era where the content management powers of WordPress could be extended for use outside the root WordPress directory on a server — whether that be an app, a hand-coded site, or even different platforms altogether. We’re no longer tethered to PHP.

This model of development is called a Headless CMS. It’s worth mentioning that Drupal and most other popular content management systems out there also offer a headless model, so a lot of what we show in this article isn’t just specific to WordPress.

In other words, WordPress is used purely for its content management interface (the WordPress admin) and the data entered into it is syndicated anywhere that requests the data via the API. It means your same old site content can now be developed as a static site, progressive web app, or any other way while continuing the use of WordPress as the engine for creating content.

Getting Started

Let’s make a few assumptions before we dive right in:

  • WordPress is already up and running.


    Going over a WordPress install is outside what we want to look at in this article and it’s already well documented.
  • We have content to work with..


    The site would be nothing without feeding it some data from the WordPress REST API.
  • The front-end is developed in Vue.
    We could use any number of other things, like React, Jekyll, Hugo, or whatever. We just happen to really like Vue and, truth be told, it’s likely the direction the Smashing Magazine project would have gone if they could start the process again.
  • We’re using Netlify..


    It was the platform Smashing migrated to, and is straightforward to work with. Full disclosure, Sarah works there. She also works there because she loves their service. 🙂

Setting Up Vue With Nuxt

Like WordPress, there’s already stellar documentation for setting up a Vue project, and Sarah has a Frontend Masters course (all the materials are free and open source on her GitHub). No need to rehash that here.

But what we’re actually going to do is create our app using NuxtJS. It adds a bunch of features to a typical Vue project (e.g. bundling, hot reloading, server-side rendering, and routing to name a few) that we’d otherwise have to piece together. In other words, it gives us a nice head start.

Again, setting up a NuxtJS project is super well documented, so still no need to get into that in this post. What is worth getting into is the project directory itself. It’d be nice to know what we’re getting into and where the API needs to go.

Learn how to set up a Nuxt app from scratch — it might be helpful to watch if you’re completely new to it. (Watch on Vimeo)

We’ll create the project with this command:

npx create-nuxt-app <project-name>

Here’s the general structure for a standard Nuxt project, leaving out some files for brevity:

[root-directory]
├── .nuxt
├── assets
├── components
        ├── AppNavigation.vue //any components you will reuse
        └── AppFooter.vue
├── dist
├── layouts
        └── default.vue //this gives you a standard layout, you can make many if you like, such as blog.vue, etc. We typically put our navs and footers here
├── middleware
├── node_modules
├── pages
├── index.vue //any .vue components we put in here will automatically become routed pages!
    └── about.vue
├── plugins
├── static
|        └── index.html
├── store
    └── index.js //we’ll put any state we need to share around the application in here, including the calls to the REST API to update the data. This is called a Vuex store. By creating the index page, Nuxt registers it.
└── nuxt.config.js

That’s about it for our Vue/Nuxt installation! We’ll create a component that fetches data from a WordPress site in just a bit, but this is basically what we’re working with.

Static Hosting

Before we hook the Vue app up with Netlify, let’s create a repository for the project. One of the benefits of a service like Netlify is that it can trigger a deploy when changes are pushed to the master (or some other) branch of a repository. We’ll definitely want that. Git is automatically initialized in a new Vue installation, so we get to skip that step. All we need to do is create a new repository on GitHub and push the local project to master. Anything in caps is something you will replace with your own information.

### Add files
git add .

### Add remote origin
git remote add origin git@github.com:USERNAME/REPONAME.git

### Push everything to the remote repo
git push -u origin master

Now, we’re going to head over to our Netlify account and hook things up. First, let’s add a new site from the Sites screen. If this is your first time using Netlify, it will ask you to give it the authorization to read repositories from your GitHub (or GitLab, or BitBucket) account. Let’s select the repository we set up.

Netlify will confirm the branch we want to use for deployments. There’s also a spot to tell Netlify what we use for the build task that compiles our site for production and which directory to look at.

We’ll be prompted for our build command and directory. For Nuxt it’s:

  • Build command: yarn generate or npm run generate
  • Directory: dist

Check out the full instructions for deploying a Vue app to Netlify for more details. Now we can deploy! 🎉

Setting Up The Store

No, we’re not getting into e-commerce or anything. Nuxt comes equipped with the ability to use a Vuex store out of the gate. This provides a central place where we can store data for components to call and consume. You can think of it like the “brains” of the application.

The /store directory is empty by default. Let’s create a file in there to start making a place where we can store data for the index page. Let’s creatively call that index.js. Sarah has a VS Code extension with shortcuts that make this setup fairly trivial. With that installed (assuming you’re using VS Code, of course) we can type vstore2 and it spits out everything we need:

And we’re off to the races! Now let’s deploy it and see what we’ve got.

Create The Ability To Select Via Tags

The last thing we’re going to do is select posts by tag. It works very similarly for categories, and you can create all sorts of functionality based on your data in WordPress, we’re merely showing one possible path here. It’s worth exploring the API reference to see all that’s available to you.

It used to be that when you gathered the tags data from the posts, it would tell you the names of the tags. Unfortunately, in v2 of the API, it just gives you the id, so you have to then make another API call to get the actual names.

The first thing we’ll do is create another server-rendered plugin to gather the tags just as we did with the posts. This way, it will do this all at build time and be rendered for the end-user immediately (yay JAMstack!)

First, we’ll store a data property that allows us to store the selectedTag. We’ll start it off with a null value.

In the template, when we click on the tag, we’ll execute a method that will pass in which tag it is, named updateTag. We’ll use that to either set selectedTag to the tag ID or back to null, for when we’re done filtering.

From there, we’ll change our v-for directive that displays the post from"post in posts" to "post in sortedPosts". We’ll create a computed property called sortedPosts. If the selectedTag is set to null, we’ll just return all the posts, but otherwise we’ll return only the posts filtered by the selectedTag:

And there you have it! All the benefits of a rich content editing system like WordPress, with the performance and security benefits of JAMstack. Now you can decouple the content creation from your development stack and use a modern JavaScript framework and the rich ecosystem in your own app!

Once again, if you wish to skip all these steps and deploy the template directly, modifying it to your needs, we set this up for you. You can always refer back here if you need to understand how it’s built.

There are a couple of things we didn’t cover that are out of the scope of the article (it’s already quite long!)

Scroll to Top