Date: May 2017
I rebuilt Surety1.com in WordPress. This included integrating a previously separate blog, creating a new custom theme, dealing with a custom post type, web design, preserving SEO, and overall creating a more user-friendly website for use by the general public.
I worked with Surety Solutions Insurance Services (aka Surety1) as a freelancer from September 2016-January 2017, and then worked in their office full time until the end of June 2017. Their website was pretty outdated, and I completely redesigned and rebuilt it on WordPress.
Just so that you’ll understand what you’re looking at, I’ll explain a little about what this company does. I’d never heard of the industry before I started working with them. They sell surety bonds, which are sort of like insurance, but not really at all. Insurance agencies can sell these bonds, but they don’t operate the same way as insurance. They’re used to protect people against things like fraud or construction projects gone bad. You can read more about it on their What is a Surety Bond? page.
So for our purposes, the important things to note are:
The old website was a gigantic mess:
I made some updates to the theme in order to fix the error messages, and I made a few improvements to some of the most important pages, but there was only so much I could do without performing a giant overhaul.
So the goals for the new website were:
This was all being done at the same time that I was overhauling the Adwords and Bing Ads accounts. Before this, the website and ads were being handled by a separate people and there was no communication between them. It’s extremely important to coordinate your landing pages with your ads so that there’s a seamless user experience.
Before I get into the details of the work that I did, let’s take a look at the Before and After images. This time, I’ve put them side by side for easy comparison.
You can see how the structure of the website is essentially the same, but it now looks like it belongs in this decade, and it’s a lot easier to understand.
These are screenshots from a 1680 x 1050 monitor (what I have at the office) and both the “before” and “after” shots are from the same display settings. The old website looks so much smaller because it was a lot narrower.
Click any to get a better view. These are large files, so I created a smaller version for the page to load, and each links to a bigger version.
(Hey look, it’s 2017)
(Custom page template)
(Not a giant difference, but it matches the rest of the site updates)
(Mainly just text here)
(Seems much more interesting and inviting while remaining simple)
(I’d already updated this particular page quite a lot, but it looks nice before and after and you can see the new landing page design with CTA boxes)
(Each state has its own flag in the corner. These pages are important because ads point to them. These are category pages for a custom post type and on a custom template.)
(This particular product is more important than others and handled by a separate department. They wanted a lead generator form on the page.)
(You can see here the different theme the blog was running on. Otherwise it’s not a huge change. A blog is a blog.)
(Individual blog post. These are informational but still link to an application form.)
(The application process is fairly involved and there’s nothing I can do about that besides make it visually easier to understand.)
(Choose an application. The first and last are green to call attention to them because they are general applications that can be used for any type of bond.)
(These forms are on Formstack.com and I don’t have too much control over them.)
This was one of the most complicated website makeovers that I’ve done. The website had been developed by various outside consultants and agencies and I didn’t have any documentation or notes from them. It was also split into two different websites and had a lot of custom WordPress features.
I jotted down some notes during the development process, but this project took three months to complete, so it would take me forever to write up every detail. If you’re one of the few who actually reads through all this, just remember that I’m glossing over a lot of things. For these portfolio entries, I try to basically document the skills I used and what I learned during the course of a big project like this one.
I tried to follow a traditional design process. Generally, you would start with some wireframes (simple blocks or outlines in black & white) to work out the structure of the pages. Then, you’d move on to filling in the images and content. But, the owner of the company didn’t “get it.” He just wanted to see designs in full color, so I ended up skipping over a lot of the process.
This is the first black & white wireframe-style design that I made:
(These images are crappy quality because I generated them from a PDF)
Then I did color versions of the homepage and a landing page with more detail:
Even with that, the owner didn’t seem to really grasp the concept of mockup designs and he never provided much feedback. There’s another manager at the company who liked the designs and better understood the concept. So I decided to just plow forward since there weren’t any big objections coming from anyone.
(These mockups were created in Adobe Illustrator CC.)
I debated whether or not to do the development work on a local installation of WordPress, but in the end I decided to do it online because that’s where it would end up anyway. I installed WordPress in a subdirectory (at surety1.com/wp/) and planned to point it at the root once development was finished.
Even this small step ended up being harder than usual. They have a web hosting company unlike any I’ve ever worked with. Maybe they’re normal, but it seems like every time I need to interact with them, it’s unnecessarily difficult. It’s a very non-managed hosting setup, meaning that they don’t do much of anything for you automatically. They even made me upgrade the Linux kernel via SSH one time. It seems crazy to me that they’d even want their clients messing with that kind of thing. I always have to explain to them that I’m not a server administrator, and I honestly don’t understand why they’re not taking care of server administration tasks themselves.
Anyway. WordPress wouldn’t install. I’ve installed it many times, following the usual official instructions, and never had a problem. But this time it would get to the end and then just give me a 404 error. Eventually I got the hosting guys to help me, and they edited the .htaccess file to allow URL rewriting. I’m still not sure why that wasn’t happening automatically like it normally does.
I also edited the robots.txt file and WordPress settings to keep bots out of the directory so that Google wouldn’t crawl and index my development website.
All of the bond pages are in a section of the website called the “Bond Info Center.” Each page is a custom post in WordPress, the custom post type being bond_info. These are the most important pages on the site because they are the equivalent of product pages and they also function as landing pages for ads.
I exported all content from the old website using the WordPress Import/Export tool. The regular pages of the website imported normally, but the bond pages would not. I figured out that I needed to create the custom post type first, so I installed Custom Post Type UI and Advanced Custom Fields. Once I created the bond_info post type, the pages imported normally.
It was also important to preserve the URLs of these pages because they all have /bond_info/ in them. I had to slightly change the naming of the custom post type, but I was able to keep the URLs the same.
There were blog posts in two places. The main part of the old website had some blog posts, and there were many more in the additional blog that was located in another WordPress installation in a /surety-blog/ folder.
The big question here was in what I should do with the WordPress permalinks. The old site was using a custom structure and the blog was in its own subdirectory, while the bond pages were their own custom post type with a corresponding URL. I honestly don’t remember now how I figured out the best thing to do, but in the end, I used the “post name” permalink settings on the new website so that the pages and regular blog posts would have normal URLs that would match the old ones. The blog posts were already being redirected in multiple ways, and I wanted to eliminate that nonsense without destroying any incoming links, so that came down to figuring out a new redirection system. (More on that later.)
I imported the blog posts from the additional blog a couple times because people kept writing new blog posts after I did the original import. That caused some duplicates that I had to go through and clean up manually.
I also discovered that people had been hotlinking to images in blog posts. So, instead of inserting an image into the post via the Media Library, they were displaying the image directly from an external source. That’s a terrible practice because the owner of that website could move or remove the image at any time. It also doesn’t give you the option of cropping the image, reducing the file size, or renaming it for SEO purposes. On top of all that, WordPress couldn’t use any of those images as Featured Images.
I ended up manually fixing all of the images in the blog posts that were written in 2017, and I created a solution to display a default featured image if none was set for the post.
I started with my Zen Life theme as a base to work from, but that was mostly to reuse the basics of the template files and some of the widgets that I’d written in the past.
This was a slightly different situation than all of the themes I built for Zen Web Themes, because I didn’t need to bake in quite as many customization options for the user. I wanted to build in some, since I knew I wouldn’t be involved with this company for the entire lifetime of the theme, but I also didn’t need to go out of my way to make every little setting customizable.
There are many chunks of content on the homepage that display with customizable widgets that I wrote specifically for this theme. There are also little custom fields here and there that the user can modify.
For example, the user can change the large image on the top-left of the page. The four boxes underneath that can be modified to change the icon, the text, and the page it links to. More custom widgets control the four “Popular Bonds” sections, where the user can choose an icon, title, and their own text or links. Below that is a “call to action bar” which is controlled by another custom widget, and the user can change the title, subtitle, button text, and button link. At the bottom, there’s a custom field that the user can modify, next to a custom WordPress loop that outputs the most recent blog post titles and featured images.
I didn’t do as much work for the WordPress Customizer because things like fonts and colors were going to be set manually. However, I left the customization options there that the Zen Life theme already had.
I also built custom templates for a variety of pages (such as their About Us, Renewals, and Performance Bond pages, among others.) The application process (step 1, step 2, and step 3) are all hard-coded and on their own custom templates. The applications themselves are built using a third-party tool called Formstack. This company has been using that for years and I obviously wasn’t involved with choosing that tool, but I did greatly improve the design of the forms. Before I got ahold of them, they all looked like they belonged to an entirely different (but equally outdated) website.
Bond Info Center Index
And it has a custom field for the US map, where I used a shortcode from the plugin that generates that.
Individual Bond Pages
The individual bond pages (acting as landing/product pages for this website) are a custom post type, as I mentioned before. They also needed their own template so that I could use a different design for these pages than for other posts or pages.
You can see the before & after of these pages above. The screenshot I took shows a page that I already updated to some extent, where I added some orange buttons throughout the text to help people find the application link.
Previously, the action the user was supposed to take was scattered around the page and not as clear as I’d like it to be. There was an “Apply Now” link near the top-right, but it was in a slider that wasn’t always visible. There was another button at the top, but that whole section was a waste of space with the blurred stock photo of business people and the additional “Bond Info Center” title. It’s also surrounded by payment icons when the person wouldn’t even be paying until much later. (Much later, in fact — after they’d gotten a quote from an agent and accepted it, which could be days later in the transaction.) Another similar button is at the bottom of the page, which was better, but still putting people off with the payment icons. Additionally, not every application link is the same, but there was no way to choose a different link for those buttons.
My new landing page design addressed all of that:
Overall, I think this is much cleaner and understandable for the end user.
There are roughly 2500 of these pages (about 50 of them for all 50 states). Each one had to be opened and saved in order for the new custom fields to take effect. While I did that, I also checked for formatting issues and other errors, just to make sure each page was displaying nicely in the new theme. I found a lot of little issues that had existed on the old site. Things like weird extra spaces, very junky old clipart images, and odd grammar mistakes. I fixed up a lot of it, but I couldn’t spend much time on each one since there were so many.
State Indexes (Categories)
These state pages have their own templates, each with an open content area (category description), a loop that displays all posts within the category, a state flag, and a sidebar.
Getting these state pages to work was one of the most difficult parts of this project. I had a hard time getting all of the code correct for the loop parameters. It should be somewhat simple to tell WordPress to loop through posts in a specific category, but it wouldn’t work for me. I kept getting all blog posts from the entire site, for example, even though I had specified only one category. All of my code seemed correct, even with lots of Googling and example-checking.
Eventually, it seemed like the only solution was to create a separate template page for each state’s category ID. Even using the same code I was using before, it would behave and display the correct posts. The good news was that it allowed me to customize each category with a state flag, but the bad news was that I think there is a better way to do it, but I couldn’t spend more time trying to figure it out. At least I got it to do what I wanted.
Over the years, this website has been redone by different people. As a result of that, there were redirects all over the place:
One of the goals of the project was to bring the blog back into the main website. It was originally /blog/, but now redirecting to /surety-blog/. I couldn’t just undo that before the launch because it would have caused all of the blog posts to redirect to the main website before it was ready. Secondly, I needed to figure out how to redirect the URLs without causing 404s. So, if some other website was linking to surety1.com/surety-blog/whatever, I need to automatically redirect that to surety1.com/whatever, based on the permalink structure I had decided on previously. I did some research and learned about Apache server mod_rewrite and regular expressions. I got that all sorted out fairly easily, but couldn’t test it properly until the end.
I also had to copy over the redirects from the old plugins. Of course the plugin being used didn’t have an export function, so I had to do a lot of it manually.
There were also other redirects happening in the .htaccess file. They were for really old URLs (things like /about-us.php now being redirected to /about-us/, which makes me wonder if the site wasn’t on WordPress originally.) Those were fine, but there was another one that was causing certain blog categories to forward to one seemingly random blog post. I got that sorted out after a while. Some of those old redirects were actually causing more SEO harm than good, I think.
Launching a website always makes me nervous. I get very afraid that something’s going to royally screw up and ruin everything beyond repair. I make backups and I do research to make sure I’m following the correct procedure, but you just never know. You can’t always follow the steps you find online because they might not work for your particular setup, and I’d already had so much trouble with this website hosting company that I figured I’d probably run into more problems. I even called them to confirm that what I was planning to do was correct, but they were useless as usual.
As I mentioned earlier, the old website was in the root folder, and the new website was in a fresh WordPress installation in the /wp/ folder. What I wanted to do was point that version of WordPress to the root while leaving the WordPress files where they were. I knew that was possible because it’s the same thing I did for the JohnEnglander.net project (except in that case, I was replacing a Drupal site.)
However, the WordPress codex doesn’t really tell you specifically how to do this. It tells you how to give WordPress its own directory, but it doesn’t tell you what will happen if you also have WordPress installed in the root directory. It has a lot of other related codex pages too, but none that I could find that addressed this particular usage scenario.
I found some instructions in a comment on some random blog post. Essentially, it says:
However, I could not overwrite the .htaccess file in the root folder because it had all those 301 redirects in it, plus, it was handling redirects related to the security certificate for the entire website. I also wasn’t completely sure what would happen with the current WordPress installation in the root folder, because it would still be attempting to display at the root domain. (I wasn’t going to wipe out those files or its database in case I needed to revert to it for some reason.)
Well, the second question is pretty easy, I think. The index file simply tells WordPress where to find the WordPress files to use. So even if there’s another instance of WordPress sitting there, it doesn’t know about it.
The .htaccess file was the bigger question. I figured that I could change the settings in WordPress, download a copy of the new .htaccess file in the /wp/ folder, and see what had changed about it. Then I could copy over those changes to the root .htaccess file without overwriting the entire file.
That didn’t end up being necessary, though. After saving the Site Address setting in WordPress, the .htaccess file in the /wp/ folder was using /wp/index.php and the rewrite rule. However, the .htaccess file in the root still needed to be . /index.php. So in the end, the .htaccess file stayed the same as it always had been.
Other than the troublesome .htaccess file, I also had to:
Everything still appears to have the same URLs before and still be indexed in Google.
During the process of updating all of the bond pages, I discovered that many of them had grammatical errors and formatting issues. There are also lots that have a very small amount of content in general. Not enough to rank in Google or even be helpful for the customer viewing the page. For the rest of the time that I worked with this company, I coordinated a small team of content writers to get this stuff updated and improved. I directed people to write some large guides for SEO purposes, and other folks are researching and writing better content for the landing pages.
If you made it through this entire post, thanks for reading it! It was a large project, and I tried to describe a little bit about the process, the things I learned, and the solutions I came up with.