This is part 7 of the 9-part series on Redesigning StevePavlina.com.
In addition to writing two of my own WordPress plugins, a significant part of this project also involved researching, testing, selecting, and configuring other quality plugins to use on my site.
The WordPress Plugin Directory has more than 44,000 plugins at the time of this writing. That’s too many to search through individually. So I rely on a few simple rules to find good plugins:
- Personal recommendations – I give a lot of weight to other people’s recommendations, especially other developers and WordPress users. I’ve learned about dozens of different plugins at the monthly Vegas WordPress meetups. The building where we meet has free Internet service provided by one of the world’s largest data centers, so it’s super speedy. When people share plugins at these meetups, I often install and try them on my laptop right at the meeting. Why wait?
- High downloads – I usually shun plugins with less than 10,000 installs. I pay extra attention to plugins that have more than 100,000 installs. If lots of people are using a plugin, that’s a good sign. I’ve found some good plugins by searching on a keyword at the WordPress Plugin Directory (or from within my admin panel itself, which uses the same directory). Then I look for listings with a high download count.
- High ratings – I usually won’t bother to try a plugin if it doesn’t have at least a 4/5 rating from users. I also pay attention to how many ratings there are. I like seeing at least dozens, if not hundreds of ratings. If there are only a few ratings so far, I’ll pass.
- Last update date – If I see that a plugin hasn’t been updated in many months or even years, I wonder if it’s been abandoned by the developer, which could mean potential security and compatibility risks for me down the road if I come to rely on it. I favor plugins with recent updates since it tells me the developer is still actively maintaining it. Some plugins that add very simple functionality don’t need frequent updates though, so I also take that into consideration.
All of this information is available at a glance on the public listings for each plugin at the WordPress Plugin Directory. These are simple guidelines, mostly common sense for people who’ve used WordPress for a while. They help me avoid risky bets on low-quality plugins.
I also try to avoid plugins that have excessive lock-in, whereby if I use them for a while, it would be hard to swap them out for a competing plugin. This is one reason I usually avoid plugins that would inject shortcodes into my posts. If I later uninstall such a plugin, the shortcodes will stop working, and my readers will see bits of code in my posts. Then I’d have to delete or replace those shortcodes in all the posts where I used them.
I look for plugins where I can predict some longevity. I ask myself, Is this plugin still likely to be around five years from now? If it seems doubtful, I pick something else. I can always check back on a promising plugin later and see if it’s gaining some traction.
Some plugins take less than a minute to install and activate, and they add functionality with no configuration needed. Other plugins have basic configuration screens that let you customize a few options. And still others have multiple screens of complex options to configure. I usually like to go through all the options and customize them right after I install a plugin. This helps me understand the plugin’s capabilities. Sometimes if I want to stretch or change the functionality a little more than the built-in options allow, such as getting a plugin to work with custom post types like my News items instead of just standard posts, I’ll do some Google searching to that end. Many plugins can be changed in ways that aren’t included with the standard documentation, usually because they take a little more skill to apply.
Let me share some specific plugins I use and why.
Jetpack is a suite of dozens of plugins created and maintained by the WordPress team. Basically Jetpack is a way to give self-hosted blogs like mine access to the features that were previously only available to sites hosted on WordPress.com.
After you install Jetpack, you can enable or disable each Jetpack plugin individually. Most of Jetpack’s plugins are free, and there are some premium paid ones as well. I’m only using Jetpack’s free ones at the moment.
I won’t go over every single Jetpack plugin I use because most of them are pretty basic, but I’ll share some of the important ones I currently have enabled.
Photon is Jetpack’s free Content Distribution Network (CDN) for speeding up image loading by distributing your site’s images on different servers around the world. Since my site isn’t very image heavy, I didn’t notice too much of a speed increase with it. But this could be very useful for an image-heavy site. You can enable it with a single click, so it’s really easy to use.
Protect will help protect your site against brute force attacks. According to my stats, Protect has already blocked more than 5300 malicious login attempts on my site in the past three weeks. Almost all of these are bots that scour the Internet searching for vulnerable WordPress blogs. I’ll share more about security a little later in this post.
Monitor reports on site downtime, so if your site goes offline for some reason, Jetpack’s server will send you an email within a few minutes to let you know.
Jetpack has a lot more features than the ones I mentioned, so I encourage you to check it out. Some of them would be especially useful if you want to connect your site with your social media accounts, such as having links to your new posts get shared on Twitter and Facebook automatically.
One type of plugin adds related posts at the bottom of each article. When a person is done reading an article, they may want to continue reading more articles on related topics. I’ve been using a plugin like this for years, and it’s one reason that many people have told me they’ll read my website for hours at a stretch.
Many years ago, one young man told me he stumbled upon my website while searching online for a way to kill himself. He ended up reading for 5-6 hours straight throughout the night, and by the time he was done, he felt a deeper sense of purpose and decided to live. So I have good reason to take this aspect of my website pretty seriously.
The plugin I used to use for this functionality seems to have been abandoned, so I decided to look for one that’s still being maintained.
One popular plugin for this purpose is Contextual Related Posts. It seemed to install and configure just fine, but despite trying many different ways to make it work, I could never get it to generate the related posts correctly. It seemed to show virtually the same small subset of suggestions on every article, and some articles showed no related posts at all. I looked for help online and found someone else who seemed to have similar problems with it, which didn’t have a solution other than trying all the things I’d already tried, such as regenerating the index and installing a sister plugin to try a different approach. I also found it to be a bit of a resource hog, so given these problems, I dropped it and decided to find an alternative. I was concerned that even if I got it working, the problems might return. I couldn’t predict a smooth run if I used it.
I ended up using Jetpack’s Related Post plugin for this feature instead, and it works great. To generate the related posts, Jetpack uploads all the content from your posts to its cloud-based server, crunches the results, and then the results become available on your site. This plugin produced decent suggestions for every article. After I submitted my site for indexing, I think the results were available in less than an hour.
Some people are sensitive to the fact that Jetpack captures all of your posts to do its processing on Jetpack’s servers. If your posts are already public though, what does it matter? Anyone could just as easily scrape your content from your public pages; there are tools to do that. Such cynicism seems misguided to me.
Unfortunately Jetpack’s default styling for its related posts clashed horribly with the style of my new website. I just thought it looked ugly and more visually complicated than necessary, with each related post in a separate box. I tried tweaking its styling with my own CSS, which turned out to be pretty challenging. Then I realized I could simply disable all of its CSS and replace it with my own, which turned out to be easier and more compact than trying to override it. I also bumped Jetpack’s default number of related posts from three to seven, so people would have more options. Three related posts seems a bit stingy.
If you like stats, then Google Analytics Dashboard for WP is a very nice plugin. You have to set up a Google Analytics account to use it. I’ve been using it for several weeks, and it’s helped me get a better sense of traffic patterns. It includes a WordPress admin bar widget that lets me view the traffic stats for any page of my site that I’m browsing.
I was really into traffic stats when I first started blogging. After a few years though, I got bored of stats-mongering and barely looked at them, often going for 6-12 months at a time without checking them. Now that the new site is online, I’m taking a renewed interest in seeing how people are interacting with the site and where they’re spending the most time.
There are some interesting patterns I can see from perusing my stats, such as:
- The top 10 countries that visit my site are the USA, United Kingdom, Canada, India, Australia, Germany, Philippines, South Africa, China, and Singapore, in that order. About 44% of my traffic is from the USA.
- 47% of visitors access my site on a desktop or laptop computer, 45% on a cell phone or similar, and 8% on a tablet.
- More than half of the people who access my site on a mobile device are using an Apple product to do so.
- 46% of visitors are female.
- 61% of visitors are 18-35 years old.
- 49% of visitors use Chrome, 31% use Safari, and 7% use Firefox for their web browser.
- Presently the most popular landing page on my site is the List of Values, which has been reprinted in numerous books. The second most popular is How to Fall Asleep in Less Than 30 Seconds. Third is Biphasic Sleep.
- There’s often an increase in traffic to sleep related articles when it’s nighttime in the USA.
- The social media site that refers the most traffic is StumbleUpon, which dwarfs the referrals from Facebook and Twitter combined. Second place is Reddit. StumbleUpon has sent me millions of visitors since I started blogging.
- About 500-600 people per day visit How to Cook Brown Rice, an article I wrote in 2007 as a joke. It’s a ridiculously basic article, but apparently a lot of people link to it and search for it. Usually several of the top 100 search terms that send me traffic are related to brown rice. This silliness eventually drove me to write a sequel in 2012, The Ultimate Rice Bowl, which isn’t nearly as popular as the original, even though it’s tastier.
- The sexuality articles are super popular, especially Getting Started with D/s Play, which is often in the top 10 articles each day. Lots of people read the sex-related articles, but hardly anyone ever mentions them, links to them, or shares them on social media. So it’ll just be our little secret. 😉
If you’re really into data or if you’re looking to grow your traffic and want to see how you’re doing, there are lots of stats plugins to choose from.
Search Engine Optimization
Some people think that good SEO is the solution to all their traffic concerns. I’m much more into HVO: Human Visitor Optimization. I tend to do well in search engines by writing for human beings, not for computers, and that’s been my approach since I started blogging. With this new website update, I’ve done a lot more to improve the design of the site for human beings as well.
I’ve seen all sorts of SEO techniques come and go over the years, and I’ve largely ignored them. I figured that Google would eventually render obsolete most attempts to outsmart its system. Instead of investing my time in learning temporary ways to earn an undeservedly high ranking through manipulation, it seemed easier to focus on helping people grow. I figured that if I wrote from that perspective, there would be a decent flow of referrals, and search traffic is just another form of referral.
In the past, SEO experts would say that it was a mistake to write such long articles. They said I should be writing 300-500 word pieces to rank better in search engines. Now they’re telling people to write 2000-word articles because apparently longer articles rank better. Google doesn’t refer as many people to the shorter pieces because content mills cranked out tons of short fluff as a way of spamming Google.
Instead of making yourself dizzy trying to play the SEO game, it’s easier, more honest, and more effective in the long run to focus your energy on creating value for real human beings and making your site better for them. If you make your site useful for people and keeping learning and improving, you’ll probably start attracting referrals and links, and search engine traffic will follow.
These days it’s nice to see that SEO has shifted further away from sneaky tactics and more towards working with Google instead of against it. I think it’s good to apply honest and cooperative SEO techniques. Avoid the sneaky stuff though; you’ll just be penalized for it later.
If I do have an SEO strategy at all, it would be to give my articles reasonably clear titles. This means not being too clever or cutesy in the choice of titles. If I write an article about gratitude, I might give it a title like Gratitude. If I write an article about How to Make Money From Your Blog, then that can be the title. I like making it easy for people to tell what an article is about just by looking at the title. Sometimes I might succumb to a clever title I really like, but most of the time my priorities are clarity and usability. When I look at someone else’s blog, and their post titles look like names of episodes from The Walking Dead, I have no clue what the content will be. This makes the site inefficient to use.
If you use good titles for human beings, they’ll tend to be good for search engines as well. There are other SEO techniques that tend to take care of themselves in this manner. Instead of thinking about SEO so much, think about making your content better and clearer for human beings. Using good subheadings and clear link text will benefit human beings and help you rank better in search engines.
Just take all the time you otherwise would have spent trying to understand Google’s search algorithms, and put it into understanding and serving your readers. Even if you only have a few readers to begin with, serve them well, and they’ll probably refer more people to your site… unless you only write about sex. 😉
I also put lifestyle considerations ahead of SEO. My site will likely incur some SEO downgrading since I deliberately avoid some things that Google likes. For instance, I quit Twitter and Facebook in 2014, so Google can’t verify my non-existent social media accounts. Consequently, it may rank my content lower because I no longer have popular social media accounts linked with this site. Maybe I seem less legitimate to Google because of that. To me this is a reasonable trade off. I like not having to deal with social media anymore, and without it I’m benefitting in other ways, such as enjoying higher personal productivity and less social drama. Not having to deal with trolling is really nice too.
As another example, I still include the year and month in the URLs for my blog posts, and the date of publication is listed below the title of every article, which may yield lower rankings for older content. Some people think it’s wiser not to include the dates in the URL or the post. I think my approach is better for human beings though since some people may want to know when an article was published. I often like knowing the publication date when I read articles on other people’s sites, so I put the date right beneath the title to make it easy to spot.
If there is a plugin to recommend here, it would be Yoast SEO, which is currently the most popular SEO plugin for WordPress. I installed it but haven’t used it much yet, other than letting it run automatically. It has a lot of different features to explore. One thing I like is that it lets me enter my own meta description for each page, so Google will display that short description to people instead of just grabbing some text off the page.
Another thing I like about Yoast SEO is that it has a built-in sitemap generator. A sitemap is a complete list of URLs for your site that makes it easy for search engines to find and index all of your public content pages. That way Google won’t miss any of your pages, even if you haven’t linked to them yet. This is an honest and cooperative SEO technique.
Initially I tried using Jetpack’s sitemap plugin, but for some ridiculous reason, its sitemaps are limited to 1000 links. Jetpack, that’s just stupid! Many WordPress sites, including mine, have more than 1000 content pages. Consequently, my Jetpack-generated sitemaps were always incomplete. I tried searching for some code that could extend this limit, but I came up blank. Fortunately Yoast SEO’s sitemap generator does not have this limitation. So I use Yoast’s sitemap generator for my sitemaps.
Reducing 404 Errors
To make sure that old links to the site didn’t just disappear, I carefully mapped old URLs to new ones and added redirects in the .htaccess file. There are plugins that can help with this, but I prefer to edit the .htaccess file directly because it’s faster for me.
This was fairly easy. It just took a bit of time since I had to review every URL on the old site and determine how it should map to the new site. I did this by typing up a list of every URL that would be changed. Most of these were old HTML files that were now managed by WordPress on the new site.
I also cleaned up the .htaccess file to neatly divide the redirects into sections with comments, which makes maintaining it easier.
I like that Yoast SEO integrates with Google Search Console. This output showed me a lot of 404 page not found errors that people were getting by using incorrect URLs to reach my site. With this knowledge I was able to make some edits to my .htaccess file by adding a few redirect rules to send people to the correct URLs they were trying to reach.
Here are some examples of bad links that were getting 404 errors:
Some of these may have happened when someone shared the link in an email and began typing another sentence right away without adding a space after the URL.
Normally these links would give 404 errors because the links are inaccurate. That’s unfortunate because it’s obvious to me what the correct links should be. Fortunately with some simple .htaccess tweaks, we can send these people to the correct locations without giving them a 404 error.
These links all go to HTML pages on my old site, which have since been turned into WordPress posts and pages with different URLs. My initial redirect for the Do It Now article looked like this:
RewriteRule ^articles/do-it-now.htm$ /blog/2005/11/do-it-now/ [R=301,L]
Unfortunately the erroneous version of the link didn’t match this pattern, so it would lead to a 404 error. All I had to do to fix it was to change the redirect to this:
RewriteRule ^articles/do-it-now.htm /blog/2005/11/do-it-now/ [R=301,L]
The only change was to remove the $ character. That character tells the redirect that this is the end of the URL. By removing the $, I’m leaving the pattern open at one end, which means there could be additional characters after the .htm, and the pattern will still match.
If you guessed that the ^ character signifies the beginning of the URL (after the domain name and the slash), you’d be correct.
And if you’re wondering why the period is followed by a backslash in the rule, that’s because a period in a regular expression represents any single character. By preceding the period with a backslash, I’m specifically referencing a period, not just any character. Of course since a period would still match any character, it would work either way.
Modifying my redirect rules to make them more resilient means that fewer people will get 404 errors. Most people who benefit from this forgiving redirect won’t even notice they had the wrong URL to begin with.
By using Yoast SEO’s Search Console feature (or by using Google Search Console directly), I can see where people are getting 404 errors, and if I can think of a good way to modify the redirect rules to help them land on the intended page, so much the better.
Again, this is about Human Visitor Optimization. Human beings sometimes make mistakes. If we can make the web server’s behavior a little less rigid, those mistakes can be bypassed.
Since WordPress uses PHP and MySQL a lot, the site would run a little slowly if I didn’t use a caching plugin (or a host that provides built-in caching such as WP Engine). My site currently runs on an dedicated server with eight CPUs, and if I disable the caching plugin, I always see the server load spike, meaning that the server is doing a lot more processing to serve up pages. This can slow down the site noticeably if there’s a lot of traffic.
Instead of having to run PHP code and load content from the database on every page view, a caching plugin saves a copy of the page when it’s first viewed. Then it serves up the saved copies to future visitors. Serving up a copy is much faster than regenerating the page from scratch every time.
Think of how long it would take you to type up a page of text and print it out. Now how long does it take to print another copy? It’s much faster to print each additional copy than it is to type the original. WordPress’ default behavior is to regenerate the original copy on every page view. A caching plugin teaches it how to save copies and to serve up the copies, unless the original actually changes.
The caching plugin I’ve been using for years is WP Super Cache. It’s a stable workhorse and very fast. The only thing I dislike about it is the truly hideous interface design. There are lots of options, and even after reading the descriptions, it’s hard to tell what some of them do. I think for people new to WordPress, the interface could seem a bit intimidating. But you should be fine if you just go with the default options.
Another popular caching plugin is W3 Total Cache. I tried it a long time ago, but I found WP Super Cache faster. I’ve seen one detailed speed comparison that also concluded that WP Super Cache outperformed W3 Total Cache on a variety of key metrics.
If your site doesn’t get much traffic, you wouldn’t likely need a caching plugin. But it sure makes a difference when your site starts lagging due to high traffic levels.
Having your site hacked is annoying to say the least. It’s happened to me several times, both with this site and the game publishing site I had until 2006. One time an attacker used my site to try to distribute Windows-based malware to people visiting our old discussion forums. I didn’t even know about it until a security researcher kindly informed me about it.
For the new site, I decided to put more effort into security since preventing a hack is generally easier (and much less annoying) than recovering from one.
A comprehensive security plugin that I currently use and recommend is WordFence. Since my site is under constant attack by bots trying to hack into it, I’ve configured WordFence to be even tougher than its defaults. If WordFence detects sneaky behavior, it will block such visitors automatically.
WordFence can even show me these attempted attacks in real-time as they’re happening. Many of these originate from China and Russia, but a lot come from within the USA too.
WordFence automatically scans the files on my website every day to make sure that none have been modified. It compares all my WordPress files to the original WordPress files for the version I’m using, and it will alert me if anything doesn’t match. It does the same for all the plugins I use too, assuming they’re in the WordPress Plugin Directory. It can do this for your themes as well if you use a theme from the WordPress Theme Directory. WordFence does additional scanning too, much like a virus scanner, to check for malware, infections, and vulnerabilities. If it finds anything, it will email you to let you know what it found.
WordFence also has some nice customization options that can detect and block attempted hacks. I set these much stricter than the defaults because by blocking attacks early, it can make the site run a little faster too. Why bother serving up additional pages to malicious bots?
I never use the default login name admin for my WordPress site. I don’t use guessable login names either, such as variations of my name. On top of that, I use a strong and lengthy password. So if any visitor goes to my WordPress login page and tries to login with a name like admin, test, stevepavlina, steve, pavlina, stevep, or spavlina, it will get blocked immediately since there are no accounts with those names. Any attempt to login with such names is a clear sign of malicious intent.
Additionally, since my site doesn’t have comments enabled, no human being would ever need to access the wp-comments-post.php file. Yet that file on my site gets hit constantly by bots trying to post comment spam. So I’ve set WordFence to immediately block anything that tries to access that file. Just loading it will trigger an immediate block.
WordFence has many other features to catch and block a variety of attack vectors. For instance, if it sees a visitor getting a high number 404 errors, it’s a safe bet that this visitor is probing the site for vulnerabilities. WordFence can automatically detect and block such visitors.
By viewing the 404 errors that WordFence was logging, I could see what malicious visitors were attempting to do. Many of them are probing for plugins that include a built-in file download script, and they’re trying to use it to download my wp-config.php file, which would give the attacker my database login and password. I’m not sure how much good that would do since they’d still need access to the server to use such info. Maybe some people use the same login and password for their WordPress database as they use for the WordPress admin or their FTP. I use different logins and passwords for all of them, so a breach of one wouldn’t automatically lead to a breach of the other.
One thing I dislike about WordFence is that it will sometimes send me scary emails for minor issues. It sends me emails with titles like this: [Wordfence Alert] Problems found on www.stevepavlina.com.
The first time I got such an email a few days after installing WordFence, I thought, Oh no! Have I been hacked already? The content of the email seemed scary at first too, telling me about a “Critical problem” found on my site. But the so-called critical problem was merely that one of my plugins had an update available. It’s good that WordFence is so on the ball when it comes to making sure I keep my plugins up to date, but I think the wording of such emails could be a tad less ominous.
It would be like if my girlfriend came into my office and shouted, “Steve! We have a major problem! I just got hungry!”
Some days later I got another WordFence email warning me of a couple files on my server that appeared to be malicious. I checked it out, but it was a false positive. WordFence was mistakenly flagging some of my cached files as malicious, but the code it was flagging was legitimate and belonged to another plugin.
Hacks often occur due to using insecure or outdated plugins, so I’m pretty strict about keeping my plugins up to date and about using quality plugins with a positive reputation. The last time I was hacked, it was due to a poorly coded plugin. I’d found some bugs in this plugin earlier and reported them to the developer, and I got the impression that the coding was a bit sloppy. I should have replaced it, but I had unfortunately come to rely on this plugin for some important functionality. That’s the sort of mistake I’d like to avoid in the future.
Even a deactivated plugin can cause a security breach if problems are later found with the plugin and its code is still on your site. This is another reason I prefer to avoid potentially dodgy plugins that look like they aren’t being updated much.
I appreciate that WordFence is constantly monitoring, scanning, and blocking attacks. If it prevents just one annoying hack, that’s terrific. And if a hack does happen, there’s a good chance it will be detected early.
At the time of this writing, I don’t have any social media sharing buttons on the site. I’m on the fence about it though.
On the one hand, these buttons add extra clutter to each page. I feel that their absence gives my site a more zen-like vibe.
On the other hand, such buttons make it easier for people to share articles with their friends, and people do use them a lot.
I’ve even had a few people email me to ask if I could add social buttons so they could share my articles. Apparently some people don’t realize they can copy and paste the link and share it on any service they want. That leaves me wondering if it would be better to add them back.
I used to have social buttons on every article and removed them in 2014 when I quit social media. I can easily restore them if people like them though. Jetpack has a plugin for this, but I’d want to style the output to look more natural for my site since the default styling is ugly.
If you have an opinion on this either way, I’d love to hear your feedback about it.
For some odd reason, WordPress’ database tables originally used a character set called latin1_swedish_ci when it first launched. This created technical problems for many bloggers when WordPress later switched character sets. I ran into some issues with foreign language characters not appearing properly, such as in words like pâté or jalepeño. I was able to apply a temporary fix, but this time I decided to do the job right and convert the whole database to the utf8_general_ci character set.
This type of conversion is a complicated process that WordPress explains how to do, beginning with the following caution:
Note: If you don’t know anything about SQL and MySQL/MariaDB you are probably screwed. This is voodoo-code territory…
Fortunately my voodoo-code skills were up to the task, and I got it done.
I also made other improvements to the database, including converting the database engine for all tables from MyISAM to the more modern InnoDB, removing tables added by old plugins that didn’t clean up after themselves when uninstalled, and fixing several other issues.
To clean up some database problems, I used the plugin Better Search Replace. This was especially helpful for fixing incorrect URLs in the WordPress Image Library. I like that this plugin can do a serialized search and replace, which was important for dealing with certain data stored in the wp_postmeta and the wp_options table.
The plugin Query Monitor was useful when I had to diagnose some SQL errors I was seeing in the error logs. It showed me which SQL queries were running on each page and how long they were taking to run.
Most bloggers wouldn’t have to deal with these types of issues. These problems largely piled up because I’d been using WordPress continuously for so many years and went through dozens of upgrade cycles. This type of database maintenance is sort of like restoring an old car. It may still run okay despite its age, but it will run better after certain repairs and upgrades are done.
Database work isn’t my strength, so I had to refresh some old skills, especially SQL. I took it slow and made frequent backups as I went along. I accidentally corrupted the database more than once along the way, but restoring from a backup only took a few seconds, so it was no big deal. I’m glad I took the time to do this extra work since now the database is in much better shape than it was when I started. It runs faster, and it should be easier to maintain going forward.
No one sees the database but me, but cleaning it up gave me a deeper sense of pride in my work. I partly felt inspired by Steve Jobs’ desire to polish even the parts that people won’t see. Holding myself to an unreasonably high standard like this definitely takes more time, but I gained a better understanding of the benefits of this philosophy. On some level it seems easier if I take pride in all aspects of my work, not just the parts that people see. It’s simpler to be consistent across the board because then you apply the same mindset to absolutely everything, instead of needing to load in different mindsets for different parts of the project. It also builds patience, which can be a hard yet highly beneficial quality to cultivate.
Since some people like to print my articles, I wrote some extra CSS code to format the articles to look nice when printed, so they wouldn’t include navigation elements. I also coded it so that images won’t be spliced in half across page borders. I styled the FAQ pages to automatically expand the FAQ items when printed and to try to avoid splicing FAQ items between printed pages. This was easy to do by using Print Preview to test my changes without wasting paper. I learned some new CSS techniques in the process too.
I added the random article feature by using the Better Random Redirect plugin. Its code is pretty simple since it only does one simple thing, so this plugin needn’t be updated often. It’s nice that this plugin works with caching too; otherwise people would get the same article every time.
Since WordPress has a notoriously awful built-in search function, especially because it lists results by date instead of relevance, I upgraded the search feature with a plugin called Relevanssi, which provides much more relevant results. Relevanssi also shows me which terms people are searching on (anonymously, not tagged to individual users).
Presently the top 15 search terms that people have used on the site’s built-in search are:
- biphasic sleep
- subjective reality
- polyphasic sleep
- law of attraction
I have articles on all of these topics, which means that people should be able to find helpful information based on their searches.
I can also see which searches are failing, most of which are due to typos, such as: lonliness, synchonicties, polifasic sleep, caffine, archieving, disipline, and prisioners. This tells me I might be able to make the site more resilient with search that can adapt better to typos.
I’ll share even more plugins that I use when I cover speed optimization in the next post.
Stay tuned for part 8, which will be posted soon.
The post Redesigning StevePavlina.com – Part 7 appeared first on Steve Pavlina - Personal Development for Smart People.