This essay originally appeared in CT No.65: The obstacle course of a website redesign along with a review of proximity chat app tool Gather.

Let’s start with the ingredients. This build started with:

  • An existing Ghost website with approximately half of my content already loaded in
  • A Substack site with a mailing list and all my content all mushed together
  • An audience with expectations that I publish a certain type of content on a semiregular basis, some of whom want to dive deeper than others
  • Loosely established content pillars, metadata and content types (i.e., essays and reviews)
  • An indeterminate non billable period before client projects would pick back up from the fall slump (I thought it would be 8 weeks but it turned out to be 3)
  • A rough deadline of “for this to be feasible it needs to be turned around before the end of the year and we are already 3 weeks into Q4” (how tech industry of me)

I expected strategic planning to take a bit, but I know some things, so it was probably the easiest part of the whole thing. The Membership Guide was invaluable in helping me research the components I needed to think through on adding a new community aspect to my business. I also deeply understand B2B media and the whole creator/newsletter economy, and I literally wrote my master’s thesis on blogging startups, so, yeah, I just made extremely informed guesses for the following questions:

  1. How much content should be behind the paywall? I went with around 30% of the essay content (or every third essay), with all reviews always free. Guides are behind the free membership paywall. “That’s not much content!” you say, but I’m a new brand, and I have a reader acquisition strategy based largely on organic search.
  2. What should I charge? The ancestral newsletterers have set the going rate between $5 and $10 for a monthly membership. I went with $7/month or $75/year, keeping my free founding 1k members policy, of course.
  3. What’s my navigation and content surfacing strategy? Some people dream about building baseball fields and billion-dollar businesses; I dream about redesigning my website’s information architecture. Pretty much the second I launch a website I immediately envision a new IA. After dissecting analytics for how visitors were (not) using my previous nav, I settled quickly on topic-based nav items with one added point of hand-curated related content beneath each post. Audiences search and think through topic-based nav more quickly than thematic- or content type-based navigation.

Once those questions were settled, I began actually building the thing, which presented its own set of obstacles.

1. Adding structure to unstructured content

Unstructured content is a pile of words and images that are interconnected, but relatively indiscernible when read by computers. PDFs are considered unstructured content: a pile of words and images on a page that can’t be separated from each other. You can add metadata to a PDF, but you can’t break it down into its component parts.

Structure makes content findable, sustainable and flexible for both humans and computers. Structured content means that a piece of content has all its relevant metadata attached. Structure makes content less like a printed page and more like a database -- aka a website. Structure that we add to content includes but is not limited to:

  • Titles, descriptions and excerpts for search, social, email and internal use (ideally all these data pieces are customizable for each medium)
  • Tags and categories (the Ghost CMS only uses tags, but plenty of other CMS use categories as well)
  • Schema markup, a metadata system that tells search engines and other software the content’s core elements
  • Image captions and alt text
  • Content elements — quotes, footnotes, lists, etc.
  • Other assets (video, embedded tweets, interactive, forms, etc.)
  • Timestamps
  • Headings

Most content management systems export content as structured data into a CSV or JSON or other data file, which you then export from your old CMS into your new CMS. After the export, you match up fields and you almost always have to optimize some fields vs. others.

Substack exported its individual posts as HTML pages, which is a kind of structure, technically. But it’s structured as HTML, which is not super helpful unless you’re using the exact same template in your new CMS than you did in Substack. If I were a developer I could write a script that pulled the content from the HTML and structured it as a JSON file to be imported into Ghost.

I am not a developer, and I knew the fastest way for me to solve the export-import problem was to copy all of my Substack posts and enter them into Ghost, updating the metadata and backdating them and splitting out the reviews from the essays. I added titles, meta descriptions, tags, image captions, alt text — all the bits that are not included in Substack (or were only recently added).

So. That took a while. But it’s worth it! Structured data is sooooo much better for search visibility and future-proofing content. Theoretically, now I can export my Ghost JSON and import it into a new CMS and I won’t have to do so much work.

2. Email list lift and shift

Ghost is like a combination Pizza Hut-Taco Bell: it’s an email service provider (ESP), member management platform and CMS all in one. I was able to import all my email addresses from Substack easily, but I wanted to ensure that my users knew what data I would collect and how I would use it.

So, a new privacy policy needed to be born, and I wanted to make sure it was written in plain language. I had to understand the personally identifiable information (PII) that Ghost would collect, plan how I would be using that data in the future, and make sure users were aware.

All I can say is: However long you think the privacy policy will take, make sure you plan for four times that estimate. (Truth: I only updated the non-legalese, and the legalese indicates far more data than I actually do. I’m getting there.)

A kid completes a messy obstacle in Double Dare [gif]
Wish I coulda done this obstacle course instead

3. Customization and theme adaptation

Ghost operates similarly to Wordpress and Squarespace, where intrepid website builders like me can purchase front-end themes from developers. There aren’t that many Ghost themes available with membership features built in, so I settled on Renge pretty quickly.

But I didn’t want Renge as it was, I wanted my version of Renge with custom colors and fonts and dots instead of hash marks and maybe not such a massive header for each post. I customized the CSS and the template files to my liking, which took for-effing-ever because I learned HTML when I was 15 and I barely know CSS and I am not an expert in responsive design nor am I a graphic designer at all, which means I mess a lot of design elements up in the process.

Luckily my partner *is* a graphic designer (but not a web designer, alas!), and he would look over my shoulder and help every so often. And when I changed my whole color palette to something slightly less neon than the Renge default colors, he gave his approval that the brand colors I selected weren’t too bonkers. (I like colors! And they are just a little bonkers and I am ok with that.)

The theme Renge also has a weirdly small header logo built-in, so we had to figure out the new logo’s embiggening without breaking the responsive design. We did, eventually.

4. And oh yeah, the image optimization

One of the cardinal rules of content-based website redesigns is: figure out your graphics dimensions as early as possible so then you can start making images that fit in your new website.

The horizontal images that worked for my old website headers would not work within the Renge theme. In fact, not all that many image dimensions looked great within the Renge theme. Vertical images looked best on mobile, but I’m running a website that’s mostly accessed by professionals on a desktop. 3:2 looks clunky on all the devices. 4:3 isn’t much better.

I thought about using the pop culture gifs that I love as the header images, but more than one of those every few posts became extremely distracting on the homepage.

“I don’t even need header images,” I informed my partner. It’s all about the text anyway.

“I think your website would be more navigable with unique header images. I like header images, and they help me understand the content of a website better,” my partner said.

I grumbled and admitted that not everyone is a text-thinker like me, most people like images and pretty colors, and returned to Canva.

I settled on a square and set about retrofitting all my old images for reviews, as well as creating new images for essays.

If you look into the archives, you will notice a fair number of posts with broken or ill-fitting images. All of these images also need alt text, and most of them need captions. I’m still working on image retrofitting and I cannot wait to be finished.

A hamster runs through a very cute obstacle course with tiny hurdles [gif]
Actual footage of me using Canva this month

5. How much metadata does my audience want to see?

In addition to simply structuring the content, I knew I needed to potentially add more tags to the content.

Last year I determined six content pillars that thematically encompass all I write about. I try to hit these themes on an even cadence, but other than knowing I have themes, I’ve done very little in accounting for them.

I love these pillars, and they help keep me on a balance of technical and cultural commentary, but I don’t think they help my audience understand my content better. So I decided to make them less prominent, with only the header color card for each post grouping the theme.

I also tag each post with the medium I’m writing about (mostly web), the content type (guide, essay or review), and the topic terms I’m discussing (SEO, UX, etc.). I toyed with making all of these tags, but I settled on the top three, which I can define in the back end. The top three tags represent the most important aspects of each post.

But there are a slew of tags on the back end, if I ever want to restructure it all.

Renge has a front-end internal search interface built-in, and I was stoked because I thought I would just set up internal search and that would be that.

Even with some guidance in the Renge theme documentation, setting up internal search (with a tool called Algolia) was wayyyyy beyond my capacity as a non-developer. I tried to make it work, follow all the documentation and implement the thing but to no avail: I have come to terms with the fact that although I know how the search engine works, I don’t know how to build or implement an internal search engine.

Another nice-to-have that was beyond my capacity: building a more robust custom template for the Tags page, or any in-depth templates at all. I may be able to figure these out eventually, but not right now.

Search will come soon. As will more features. But in the meantime, all the nice search features that came with the Renge theme are commented out and hidden from view.

So there you have it: my minimum viable product.

Hand-picked related content

The link has been copied!