Update 2023-02-11 : Added an additional check (modify “apache2.conf” file) at the end of the article in the case the existing method doesn’t work.
As I was reviving this site after its two-year hiatus, I noticed that I neglected to post an article detailing how to set up WordPress permalinks. Since it requires some modifications on the server side it took a bit of trial-and-error to re-enable it. If even I could forget how to make the settings after two years, then it is definitely reason enough to make an article out of it (for my own sake!).
Read on to learn more about why and how to set WordPress permalinks.
As this article serves as more of an appendix to the previous wordpress articles, I will NOT be linking this article to previous WordPress tutorials (for now… in the future I’m considering to link articles by keywords/hashtags). However, I will provide the previous tutorials for how to get a WordPress site up-and-running using Google Cloud below, so do check them out if you’re interested:
Table of Contents
Why Permalink?
There are many pages scattered around the internet explaining why permalinks are so important – almost to the point where it should be necessary – so I will try not to repeat what others are saying and add my own spin to the importance of permalinks.
Everyone who has initialized a WordPress site knows that the default page linking is via the “p” query parameter which points to the row number in the WordPress database where the article exists. There are a number of problems with the second half of the previous sentence (other than the grammar issues… I know!), but below are some reasons why:
“?p=123”
What does the query parameter “p” stand for? “Page”? “Post”? “Parameter”? What significance does it have with the contents of the page (By the way, the answer is “None Whatsoever”).
This parameter naming is quite ambiguous and doesn’t leave any impact to the user. Nowadays browser bookmarks or URL autofill technologies are also searchable by Page Title which diminishes the issue, but a sole “p” parameter doesn’t tell the reader anything about the category nor the contents of the page.
Query Parameters Are Growing Weaker
Query parameters are becoming the subject of growing debate over the past few years. Some sites pass tokens or keys as query parameters which cause bloating and cluttering of the URL. SEO performance also takes a hit when you are using the default permalink structure WordPress provides (“p” parameter above). Apple’s mission to protect Safari users’ privacy included a release which strips query parameters when navigating from a site flagged by ITP’s model used for detecting whether the site tracks users in an invasive manner. Lastly, analytics tools such as Google Analytics may strip query parameters in order to make reports cleaner – this means that if you control your page content via query parameters such as “p”, then they may all be analyzed and clumped together as one single entity.
URL Path vs Query Parameters
There is a common best practice (at least for developing REST APIs) that the URL should contain the resource to be accessed while the query parameter be used to filter its results. If you consider the WordPress database as a collection of articles, then it would seem alright to use query parameters to filter the relevant articles. However, WordPress by default has no easy way to implement this since, AFAIK, there are no other parameters other than “p” for filtering posts from the WordPress database. Thus, as an alternative, it would make more sense to use URL paths structure the URL to something like “www.example.com/post/category/topic“.
Setting Up WordPress Permalinks
In the case of GCP’s WordPress Click-To-Deploy feature, WordPress is hosted using Apache, and therefore Apache needs to be reconfigured to allow rules for WordPress permalinks. The guide below breaks down the process into two parts – server and client (WordPress Admin) side. But before we get started, this post is made as of April 24, 2020, with the GCP Compute VM instantiated the day before (April 23, 2020). Thus the VM will have the following configurations, and you will need to adjust accordingly for any future changes in VM configuration:
- Debian 9.11 (“Stretch”)
- Apache 2.4.25
- WordPress 5.2.3
Server-Side : Modify Apache Configurations
SSH into your VM instance.
The following screenshots are all taken from GCP’s SSH interface.
For GCP’s click-to-deploy instance, there should be a “wordpress.conf” in apache2 subdirectory. Check that it exists with the following command:
ls -al /etc/apache2/sites-available/wordpress.conf
If it exists, then this is the file you will need to modify. Go ahead and open it up with vim (or whatever editor you prefer):
sudo vim /etc/apache2/sites-available/wordpress.conf
If it the above DOESN’T exist, it’s okay, the above command will create a new file for you so just paste in the “final result” section just down below and save.
You will need to add the following parameters under the “Directory” section:
Options FollowSymLinks
AllowOverride All
Your final result for the file contents should look something like as follows:
<Directory /var/www/html>
Options FollowSymLinks
Options -Indexes
AllowOverride All
</Directory>
Save and exit (using “:x” for vim). Afterwards, run the following command to restart Apache:
sudo service apache2 restart
WordPress Admin : Change Permalink Settings
Admin settings are very easy: head on over to the Permalinks settings using the following link (replace hostname with the hostname of your site):
${{HOSTNAME}}/wp-admin/options-permalink.php
I prefer to use “Post name” as it is the most simple and gets the point across. Whatever change you decide to make, make sure to hit “Save Changes” at the bottom to reflect the changes.
If it doesn’t work, check apache2.conf
Some folks may have another setup or use updated versions of some software to run their WordPress site. If the above guide doesn’t work, then you may be able to fix it by modifying the /etc/apache2/apache2.conf configuration. If this file exists, change the AllowOverride setting inside of the “<Directory /var/www/>” to AllowOverride All. Below is what I have for my apache2.conf:
<Directory /var/www/>
AddType application/x-httpd-php .htm
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
Done!
Your permalinks settings should now be active and all of your pages should now reflect its permalinked version. There are multiple ways to test whether it’s working, such as simply clicking on a post on your website, or checking “preview mode” of a post you are currently editing. If it is not to your liking, you can always just change it at any time via the Permalinks setting. However, a word of warning: changing your permalink will require all your pages to be re-indexed, and as a consequence your SEO performance will fall considerably. It is wise to consider and set your permalink preferences in stone so that you will not have to change it in the future and risk your site performance.