DEV Community: Sergey Li

Programmatic SEO with Handlebars

Sergey Li — Thu, 12 Sep 2024 08:41:25 +0000

When it comes to SEO, there are two main strategies: targeting big, popular keywords or focusing on smaller, more specific ones (niche keywords).

Targeting big keywords means intense competition. It requires significant resources, including time, money, and expertise. Large companies with substantial budgets often dominate these popular search terms, making it difficult for smaller businesses or newcomers to rank well.

If you're just starting out or have limited resources, focusing on niche keywords is often a better strategy. This approach allows you to target less competitive search terms that are more specific to your product or service. It's an effective way to attract a targeted audience without directly competing with industry giants.

However, the niche keyword strategy has its challenges. To generate significant traffic, you need to target many of these smaller keywords. Creating content for each keyword individually can be time-consuming and labor-intensive. This manual approach might not be practical when you're trying to cover a large number of keywords.

This is where programmatic SEO becomes valuable.

What is Programmatic SEO?

It's a method that allows you to create content for many niche keywords automatically. Instead of making each page by hand, you use a system that generates many pages at once, each targeting a different keyword.

Let's look at two examples that show how programmatic SEO can work wonders when done right:

Crontab Guru by Cronitor

Cronitor, a company that monitors cron jobs, created a clever tool called Crontab Guru. This tool helps developers who often struggle with cron job schedules.

Developers frequently search for phrases like "Cron job every hour" or "Cron job every Monday." Crontab Guru smartly creates a unique page for hundreds of these time combinations. Each page provides the exact code needed for that specific schedule.

This simple idea attracts about 120,000 visitors monthly from search engines. It also subtly introduces people to Cronitor's paid services.

Thomas Cook's Weather Pages

Thomas Cook, a travel company, used programmatic SEO to create a vast network of weather-related pages for their destinations. They started by looking at what people search for about popular vacation spots.

For a place like Tenerife, instead of just one general weather page, they created many specific ones. They made pages for "Tenerife weather in January," "Tenerife weather in February," and so on. They even created pages for different towns within Tenerife.

They repeated this idea for all their travel destinations. In total, Thomas Cook created 3,744 different weather pages. These pages collectively bring in nearly 500,000 visitors every month from search engines. For Tenerife alone, they have 67 different weather pages.

If you examine these pages closely, you'll notice a fundamental aspect of programmatic SEO:

Crontab Guru pages utilize a consistent template, with variations primarily in the URL, meta title, H1 tag, and the specific cron syntax. The overall structure and surrounding content remain uniform across pages.

Similarly, Thomas Cook's weather pages employ a standard template. The main differences lie in the destination name, month, and specific weather data. The page structure and types of information presented are consistent across all locations and time periods.

This templated approach is key to programmatic SEO. It allows for efficient creation of many pages, each targeting specific keywords.

So, how can we create these pages effectively? At TextPixie, we found that Handlebars is an excellent solution for this. Handlebars is a templating engine that's perfect for programmatic SEO. Let's explore how we can use it to generate SEO-optimized pages at scale.

Handlebars for Programmatic SEO

At TextPixie, we have created a 4 steps approach to generate SEO-optimized pages at scale leveraging Handlebars.

Page Template Creation: We use Handlebars to create a page template with HTML and CSS. This template serves as the foundation for all our generated pages.
String Abstraction: We abstract the text content on the page as i18n keys. Crucial SEO elements like meta titles and H1 tags are set up with variables to allow for customization.
Content Storage: All the strings are stored in an i18n system. This centralized approach makes it easy to manage and update content across multiple pages.
Dynamic Rendering: During page rendering, we collect the necessary variables and use Handlebars.compile() to generate the final strings. This process allows us to inject the right content into each page dynamically.

Let's look at a real example of how this works:

Page Template Creation:

We create a Handlebars template for a translation service page:

<!DOCTYPE html>
<html lang="{lang}">
<head>
    <title>{metaTitle}</title>
    <meta name="description" content="{metaDescription}">
</head>
<body>
    <h1>{h1}</h1>
    <p>{introText}</p>
    <div class="translator">
        <textarea placeholder="{placeholderText}"></textarea>
        <button>{buttonText}</button>
    </div>
</body>
</html>

String Abstraction:

We define i18n keys for our content, with variables for language pairs:

const i18nKeys = {
    metaTitle: "{{sourceLang}} to {{targetLang}} Translator: Free and instant translation",
    metaDescription: "Translate {{sourceLang}} to {{targetLang}} quickly and accurately with our free online translator. Perfect for texts, websites, and documents.",
    h1: "{{sourceLang}} to {{targetLang}} Translator",
    introText: "Instantly translate {{sourceLang}} to {{targetLang}} with our translator",
    placeholderText: "Enter text to start translation",
    buttonText: "Translate"
};

Content Storage:

These strings are stored in our i18n Google Sheet. Each key in the i18nKeys object corresponds to a single entry in the i18n Google Sheet. The values contain Handlebars-style placeholders ({{sourceLang}}, {{targetLang}}) where appropriate.

Dynamic Rendering:

When we need to use these values, we first fetch the template string from the i18n system, then compile it with Handlebars, passing in the necessary variables:

const getI18nValue = (key, variables) => {
    const template = Handlebars.compile(i18n.t(key));
    return template(variables);
};

// Usage example
const metaTitle = getI18nValue('metaTitle', { sourceLang: 'English', targetLang: 'Spanish' });

This approach allows for more flexibility and reusability, as the same template can be used for multiple language pairs by simply changing the variables passed to it.

By implementing this system, we can efficiently generate numerous pages, each optimized for specific keywords related to different language pairs, while maintaining a consistent structure and design.

Our Textpixie AI Translator page and all its subpages are sharing the same template, e.g., English to French Translator. Check them out to see them in action.

Managing and retrieving translated strings in a Google Sheet

Sergey Li — Wed, 04 Sep 2024 09:55:44 +0000

In my previous article, I discussed how we at TextPixie implemented a straightforward solution for managing multilingual routes in our Express-based application. In this article, I will dive deeper into the second requirement of our i18n solution: managing and loading translated strings for our web pages.

By the end of this article, you'll have a clear understanding of how we've implemented a simple yet effective i18n solution that allows us to quickly translate our pages and content, making TextPixie accessible to users around the world.

I18N Workflow

At TextPixie, we use a straightforward process to make our website available in multiple languages. It's a three steps process.

1. String Management

We store all our text strings in a Google Sheet. This sheet is like a big table. The first column contains "keys" - unique identifiers for each piece of text. The other columns contain translations for each language we support. For example:

key	en	zh-tw
hello	Hello	你好
welcome	Welcome	歡迎
start_button	Start	開始

This setup makes it easy for our team to add or update translations without needing coding skills.

2. Database Storage

We use a simple script to copy all the strings from our Google Sheet into a SQLite database. This database acts as a quick-access storage for our app. Whenever we update the Google Sheet, we run this script to keep the database in sync with the latest translations.

3. Using Translations

When someone visits our website, we first check extract the language in the URL and store it to req.locale so that the matched route handler is aware of which language it should display. Then for each page, we fetch only the strings needed for that page in the correct language. We use these strings to build the page, ensuring it displays in the right language for the user.

Implementation

1. Database Structure

Our i18n solution uses a SQLite database to store translations. The database schema is defined as follows:

CREATE TABLE IF NOT EXISTS "i18n" (
    "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
    "locale" TEXT NOT NULL,
    "key" TEXT NOT NULL,
    "string" TEXT NOT NULL,
    "created_at" TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL,
    "updated_at" TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL
);
CREATE UNIQUE INDEX IF NOT EXISTS idx_i18n_locale_key on i18n("locale", "key");

This structure allows us to store translations for multiple languages efficiently. The locale and key columns together form a unique index, ensuring that we don't have duplicate entries for the same key in the same language.

2. I18N Class

We've created an I18N class to handle interactions with the database. Here are some key methods:

export class I18N {
    constructor(db) {
        this.db = db;
        this.createDb();
    }

    createDb() {
        try {
            return this.db.exec(schema);
        } catch (error) {
            console.error("Failed to create database schema:", error);
        }
    }

    insertRow(locale, key, string) {
        // ... implementation ...
    }

    getRows(locale, keyPrefixes) {
        // ... implementation ...
    }

    getStringByKey(locale, key) {
        // ... implementation ...
    }

    // ... other methods ...
}

The insertRow method is used to add or update translations in the database, while getRows and getStringByKey are used to retrieve translations.

3. Populating the Database

We use a script to populate our database from the Google Sheet. Here's a simplified version of how we insert data:

function saveGoogleSheet(sheetData) {
    let headers = sheetData.values[0];
    for (const row of sheetData.values.slice(1)) {
        let key = row[0];
        for (let i = 1; i < headers.length; i++) {
            let locale = headers[i];
            i18n.insertRow(locale, key, row[i]);
        }
    }
}

4. Using Translated Strings in Express route handler

In our Express routes, we use the I18N class to fetch translations according to req.locale set by the extract locale middleware in our previous article. Here's an example of how we might use it in a route handler:

app.get('/:locale/welcome', (req, res) => {
    const i18n = new I18N(db);

    const welcomeMessage = i18n.getStringByKey(req.locale, 'welcome_message');
    const pageTitle = i18n.getStringByKey(req.locale, 'page_title');

    res.render('welcome', { 
        welcomeMessage: welcomeMessage.string, 
        pageTitle: pageTitle.string 
    });
});

Conclusion

Implementing this i18n workflow has significantly improved our ability to manage and deliver multilingual content for TextPixie. By leveraging a Google Sheet for content management, a SQLite database for efficient storage and retrieval, and integrating seamlessly with our Express.js application, we've created a system that is both powerful and user-friendly.

By sharing our approach, we hope to provide insights and ideas for other developers facing similar internationalization challenges. This solution has worked well for TextPixie, but as with any implementation, it's important to consider your specific needs and constraints when designing an i18n system for your own projects.

To see this i18n solution in action, visit TextPixie AI Translator and try switching between languages.

A Simple Way to Handle Locale-Specific URLs in Express

Sergey Li — Wed, 28 Aug 2024 03:52:47 +0000

Introduction

At TextPixie, as we expanded our AI Translator to support multiple languages, we needed a straightforward internationalization solution that would work with our existing Express-based backend, which doesn’t have built-in i18n support.

While we considered using i18next, we found that it offered much more than we needed and would complicate our backend. Instead, we decided to build a custom solution that focused on the two key requirements for our project:

Setting up locale-specific URLs.
Managing strings in Google Sheets and loading them onto pages based on the locale in the URL.

In this article, I’ll walk you through how we implemented locale-specific URLs using a simple Express middleware. In a follow-up article, I’ll dive into how we manage strings in Google Sheets and load them onto pages based on the locale in the URL.

The Problem

When we started expanding our AI Translator, we knew that to make the app truly multilingual, we needed clean, accessible URLs for each supported language. Ideally, our URLs would look something like this:

https://textpixie.com/ (English Homepage)
https://textpixie.com/zh-tw/ (Traditional Chinese Homepage)
https://textpixie.com/image-translator (English Image Translator)
https://textpixie.com/zh-tw/image-translator (Traditional Chinese Image Translator)

Our initial approach involved defining routes in Express like this:

app.get('/:lang/', homepageHandler);
app.get('/', defaultHomepageHandler);
app.get('/:lang/image-translator', imageTranslatorHandler);
app.get('/image-translator', defaultImageTranslatorHandler);

However, this method quickly led to two significant issues:

Route Conflicts: The /:lang/ route could unintentionally match URLs meant for other pages, such as /image-translator, leading to incorrect page rendering.
Code Duplication: We had to define multiple routes for each page to handle different languages, which resulted in repetitive and hard-to-maintain code.

Our Middleware Solution

To overcome these challenges, we developed a simple Express middleware function:

function extractLocale(req, res, next) {
    const pathParts = req.path.split("/").filter(Boolean);
    const firstDir = pathParts[0];
    if (checkLocalsExisted(firstDir)) {
        req.lang = firstDir;
        req.url = req.url.replace(`/${firstDir}`, "");
    } else {
        req.lang = "en";
    }
    next();
}

This middleware does two key things:

Locale Extraction: It checks if the first part of the URL is a valid locale (e.g., “en” or “zh-tw”).
URL Rewriting: If a valid locale is found, it removes the locale from the URL and stores it in req.lang, allowing the rest of the app to process the request without worrying about the locale prefix.

Implementation

We integrated this middleware into our Express application as follows:

const express = require('express');
const app = express();

app.use(extractLocale);

app.get('/', homeHandler);
app.get('/image-translator', imageTranslatorHandler);

Here’s how the middleware processes different URLs:

https://textpixie.com/
- req.lang: "en" (default)
- req.url: "/"
- Matched route: app.get('/', homeHandler)
https://textpixie.com/zh-tw/
- req.lang: "zh-tw"
- req.url: "/"
- Matched route: app.get('/', homeHandler)
https://textpixie.com/image-translator
- req.lang: "en" (default)
- req.url: "/image-translator"
- Matched route: app.get('/image-translator', imageTranslatorHandler)
https://textpixie.com/zh-tw/image-translator
- req.lang: "zh-tw"
- req.url: "/image-translator"
- Matched route: app.get('/image-translator', imageTranslatorHandler)

This setup allows us to use a single route definition to handle multiple locales, simplifying our codebase and making it easier to maintain. The middleware ensures that the correct locale is extracted and handled without the need for duplicating routes.

Conclusion

By implementing this simple Express middleware, we were able to create a clean and efficient solution for handling locale-specific URLs in our web app. This approach helped us avoid route conflicts, reduce code duplication, and streamline our internationalization process.

In a follow-up article, I’ll dive into how we manage strings in Google Sheets and load them onto pages based on the locale in the URL. This second step is crucial for ensuring that the right content is displayed to users based on their language preference.

If you’re interested in seeing this solution in action, check out TextPixie AI Translator to experience how we handle multilingual content.

This article was originally published at TextPixie Blog.