DEV Community: ManTek Technologies

Short links that outlive the vendor: a newsroom URL shortener on WordPress and AWS

Jaafar Abazid — Wed, 24 Jun 2026 20:32:21 +0000

An editor hits publish on a breaking story and pushes it to a million followers.
The headline is sharp. The link beneath it is forty characters of
%D8%A7%D9%84%D8%B0..., unreadable, often cut off by the platform, telling the
reader nothing about where the tap will take them.

That is what a long URL looks like on social when the slug is Arabic. WordPress
stores and emits the slug percent-encoded, so a clean Arabic headline turns into
a wall of %XX bytes the moment it leaves your site:

/الذكاء-الاصطناعي  →  /%D8%A7%D9%84%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D9%84%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A

(We have written before about how those Arabic slugs get truncated in the first
place. This is the other half of the
story: what happens to them out in the world.)

Every serious newsroom solves this the same way, with branded short links:
sho.rt/9Kx2a instead of the wall of bytes. Short, on brand, and the same length
whether the article is Arabic, English, or anything else. The only real question
is whether you buy that capability from a service like Bitly or TinyURL, or build
it yourself.

We did both, on purpose. Here is why, and how.

Why both

A short link, once shared, is effectively permanent. It lives in tweets, Telegram
channels, WhatsApp forwards, and printed QR codes for years. So the day a vendor
raises its prices, retires a feature, or simply shuts down, every one of those
links dies, and the traffic with them. For a newsroom whose archive is its
capital, that is not an acceptable dependency.

So we set one rule: the ability to resolve our own short links must never depend
on a company we do not control. Buy the convenience, own the lifeline.

In practice that means Bitly serves the short domain today, because it gives the
newsroom polished click analytics and a link UI editors like. But sitting behind
it, fully in sync, is an in-house resolver running on our own AWS edge, ready to
take over with a single DNS change. The reader never sees the seam, because the
short codes are identical on both fronts. This runs on the same WordPress and AWS
stack we have written about before:
WordPress on EC2 behind an Application Load Balancer, Aurora for the database, and
CloudFront at the edge.

One short code, two interchangeable fronts. DNS decides who answers, so failover is a single DNS change, and the reader always lands on the same canonical article.

The one decision everything hangs on

Before any infrastructure, there is a single design choice that makes the rest
possible: one short ID, minted once in WordPress, reused everywhere. The same
string is the key in our database, the key in DynamoDB, and the custom back-half
on Bitly.

Because 9Kx2a is literally the same value in all three places, switching who
answers the short domain is invisible to anyone holding the link. There is no
remapping, no lookup table between vendors, no links left behind. That one
decision is what turns "own the lifeline" from a slogan into a DNS change.
Everything below serves it.

Generating the ID

The ID is drawn from a 64-character, URL-safe alphabet: A-Z, a-z, 0-9, plus
- and _. Those 64 characters all live in a URL path without encoding, so the
short link stays clean no matter what.

We generate it only when a post is published, never on draft. That keeps the
keyspace clean (no IDs burned on posts that never go live), avoids leaking a URL
for unpublished work, and means a short link never resolves to a 404 or a private
draft. A short link should only ever exist for something a reader can actually
read.

The generator uses a cryptographic random source, not rand(), so codes are not
guessable or enumerable, and it leans on a UNIQUE constraint to stay correct:

const SHORTLINK_ALPHABET = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_';
const SHORTLINK_LENGTH   = 5;  // 64^5 ≈ 1.07B. Use 6 for ≈ 68.7B of headroom.

function mantek_generate_short_id(): string {
    $alphabet = SHORTLINK_ALPHABET;
    $max      = strlen( $alphabet ) - 1;
    $id       = '';
    for ( $i = 0; $i < SHORTLINK_LENGTH; $i++ ) {
        $id .= $alphabet[ random_int( 0, $max ) ];  // CSPRNG: not guessable
    }
    return $id;
}

// Runs on the publish transition only. The UNIQUE index on short_id turns a
// collision into a failed INSERT, so we simply re-mint and try again.
function mantek_assign_short_id( int $post_id ): string {
    global $wpdb;
    $table = $wpdb->prefix . 'short_links';

    for ( $attempt = 0; $attempt < 5; $attempt++ ) {
        $short_id = mantek_generate_short_id();
        $inserted = $wpdb->query( $wpdb->prepare(
            "INSERT INTO {$table} (short_id, post_id, full_url, provider, status, created_at)
             VALUES (%s, %d, %s, %s, 'active', NOW())",
            $short_id, $post_id, get_permalink( $post_id ), mantek_active_provider()
        ) );
        if ( false !== $inserted ) {
            return $short_id;  // clean insert: the ID was free
        }
        // Duplicate key (MySQL 1062): the ID was taken. Loop and re-mint.
    }
    throw new RuntimeException( "Could not mint a unique short_id for post {$post_id}" );
}

A fair question: with random generation, will codes collide? Yes, and you must
plan for it rather than hope. The maths is the birthday problem, not the raw
keyspace: at five characters you have a better-than-even chance of some
collision once you have minted roughly 38,000 links, which a busy newsroom passes
within a year. That is exactly why the UNIQUE constraint and the retry loop are
not optional.

What that maths does not mean is that the retry fires often. The chance that any
single new code clashes is the number of live links divided by the keyspace, so
even at a million live links roughly one insert in a thousand needs a second try,
and a third try is a one-in-a-million event. Five characters with the retry is
comfortable essentially forever; six characters (about 68.7 billion) makes the
retry all but theoretical, at the cost of one extra character. Pick five unless
you want the longest possible runway.

Where the mapping lives

The short code needs a home in WordPress. The tempting shortcut is the existing
guid column on wp_posts, since it already holds something URL-shaped. Resist
it (more on why in a moment). We use a dedicated table instead:

Column	Role
`short_id`	the code itself, with a `UNIQUE` index for the retry loop and the reverse lookup
`post_id`	the local post this code is attached to, used to refresh `full_url`; instance-local, never used for resolution
`full_url`	the article's current canonical URL, a pointer we refresh when it changes
`provider`	which backend was active when the code was minted (`bitly`, `inhouse`); a historical marker, since the DNS is the real router
`status`	lifecycle: `active`, `pending`, or `gone`, so the resolver knows what to do when a post is unpublished
`created_at` / `updated_at`	timestamps for reconciliation

A dedicated table owns its own schema, is properly indexed for the reverse lookup,
and has zero blast radius on the rest of WordPress.

Why not just reuse the guid column? Because the GUID is not a usable URL,
despite looking like one. Its real job is to be a permanent, never-changed
identifier that feed readers use to decide whether an item is new. Overwrite it
and you risk re-notifying every subscriber, breaking the WXR importer's
de-duplication (and newsrooms migrate often), and corrupting media references,
since for attachments the GUID is the real file URL. Indexing it also means
altering a core table. A dedicated table avoids all of that for almost nothing.

Resolving at the edge: redirect, not proxy

Here is the most important architectural decision, and the one most people get
subtly wrong. A short link should redirect. It resolves the code to the
article's URL and returns a 301, and the reader's browser then loads the real
article from the normal stack. The short-link layer never fetches or serves the
article's HTML itself.

The alternative, serving the article's HTML under the short URL, is a trap. It
splits every article across two URLs, which confuses search engines and forces
canonical-tag gymnastics, it leaves the reader looking at a sho.rt address
instead of your trusted domain, and it doubles your cache, since CloudFront now
stores the full article twice. The redirect keeps the short-link layer trivially
small: the cached object is a few hundred bytes, and it points everyone at the one
canonical article.

That also dissolves a performance worry worth naming. Resolving a short link is
one key lookup followed by a redirect. It never disassembles the full URL into
date, category, and slug, and it never runs a WP_Query. WordPress already
resolves its permalinks once, for all traffic, and CloudFront caches the result.
The short link does not add that cost; it just prepends a tiny redirect hop in
front of it.

The in-house path works like this. The short domain's DNS points at CloudFront. On
a cache hit, CloudFront returns the cached 301 immediately, with no compute at
all. On a miss, it runs a small Lambda@Edge function that does a single DynamoDB
lookup on the short code, builds the redirect, and caches it for next time:

// Lambda@Edge, viewer-request on the short domain's CloudFront distribution.
// Resolves /<short_id> to a 301 toward the article's current URL.
const { DynamoDBClient, GetItemCommand } = require('@aws-sdk/client-dynamodb');
const ddb = new DynamoDBClient({ region: 'us-east-1' });

exports.handler = async (event) => {
  const request = event.Records[0].cf.request;
  const shortId = request.uri.replace(/^\/+/, '').split('/')[0];
  if (!shortId) return notFound();

  const { Item } = await ddb.send(new GetItemCommand({
    TableName: 'short_links',
    Key: { short_id: { S: shortId } },
    ProjectionExpression: 'full_url, #s',
    ExpressionAttributeNames: { '#s': 'status' },
  }));

  if (!Item || Item.status?.S === 'gone') return goneOrNotFound(Item);

  const target = Item.full_url.S;
  if (!isOwnDomain(target)) return notFound();  // open-redirect guard

  return {
    status: '301',
    statusDescription: 'Moved Permanently',
    headers: {
      location:        [{ key: 'Location',      value: appendUtm(target) }],
      'cache-control': [{ key: 'Cache-Control', value: 'public, max-age=86400' }],
    },
  };
};

A DynamoDB lookup on the partition key is single-digit milliseconds, and most hits
never reach it anyway, because CloudFront is serving the cached redirect. One
detail to know: a Lambda@Edge function is authored in us-east-1 and replicated to
every edge, and its DynamoDB call reaches the table's home region, so for global
low latency you either replicate the table with DynamoDB Global Tables or front it
with DAX. In practice it rarely bites, precisely because the cache absorbs the vast
majority of requests.

A few decisions baked into that function:

301, not 302. We want search engines to consolidate the article's ranking signals on the canonical URL, and they treat the 301 status itself as that signal. The explicit Cache-Control keeps the redirect from being pinned forever in browser caches, so a later URL change is still picked up.
Open-redirect guard. The resolver only ever sends readers to our own domains. An unknown or tampered target returns a plain 404, so the shortener can never be abused to bounce users to a phishing page. Random codes make scanning for valid links low-yield too.
API Gateway, honestly. You will see URL shorteners put API Gateway in this path. Its only real job there is to expose a regional Lambda to CloudFront as an origin. For a pure redirect you usually do not need it: Lambda@Edge resolves directly, and where a regional function is preferred, a Lambda Function URL is a lighter front door. (This architecture already runs API Gateway, but for headless apps, not for the shortener.)

Resolving the short link is one cached redirect at the edge, with a DynamoDB lookup only on a cache miss. The browser then follows the 301 to the article through the normal stack, exactly like any other reader.

Migration-proof by design

Notice what we actually resolve by. The durable handle is the short_id itself,
the value we mint, control, and put out into the world. The full_url is just a
pointer we keep current beside it. That pairing is what lets a short link outlast
not only a vendor but your own URL scheme.

It is worth being precise about why, because the obvious candidate for a permanent
identity, the WordPress post_id, is not actually stable. Post IDs are
auto-increment integers local to one database; migrate to a fresh WordPress (or to
anything else) and they get reassigned. So we never resolve by post_id. We
resolve by the short_id, and we carry the short_id → full_url mapping across
every migration, refreshing full_url to wherever the article now lives. Newsrooms
re-platform, restructure categories, and change permalink patterns over the years,
and each time the old URLs change. A short link keyed on the ID we own does not
care: share sho.rt/9Kx2a once, and it keeps landing on the right article through
every future migration, because resolution ends at a code we control, never at a
database's internal ID or a frozen URL string.

The one rule that keeps this true: when an article's URL changes, update the
full_url in DynamoDB and invalidate the cached redirect. Active invalidation is
the primary mechanism, so the change is picked up at once, and the bounded
Cache-Control is a safety net that heals anything an invalidation missed within a
day. For an everyday slug edit, invalidate the single path. For a mass migration of
thousands of URLs at once, let a short TTL expire instead, since firing thousands
of individual invalidations is slower and costlier. This is also why the serving
mapping lives in DynamoDB rather than only inside WordPress: it sits outside the
CMS, so it survives any migration by definition. After a re-platform you refresh the
full_url values to the new URLs, and every link already in the wild keeps
resolving.

Keeping the stores in sync at publish

When a post goes live, three things happen in order: WordPress mints the ID into
its own table, upserts the mapping into DynamoDB, and calls the active shortener.
Each store has a clear, non-overlapping role:

Store	Role
WordPress (`wp_short_links`)	Authoring source of truth: mints the ID, knows the canonical URL
DynamoDB	Serving source of truth at the edge, and the vendor-neutral warm standby
Bitly	Downstream replica: the active analytics front today, and swappable

The honest complication with writing to three places is partial failure: the
DynamoDB write succeeds but the Bitly call times out, say. So the external call
goes through a small queue (SQS) with retries, so a transient blip never silently
loses a mapping, and a periodic reconciliation job diffs WordPress against
DynamoDB and Bitly to catch any drift. WordPress is always the tie-breaker.

On publish, WordPress mints the id and writes its own table, then upserts DynamoDB and enqueues the Bitly call through SQS, so a transient failure never loses a mapping. WordPress stays the source of truth.

Why Bitly, and how we keep it swappable

The call to the shortener does not name Bitly. It goes through an interface, so
Bitly is one implementation behind a contract the rest of the code never has to
think about:

interface ShortLinkProvider {
    public function create( string $shortId, string $fullUrl ): ShortLinkResult;
    public function updateTarget( string $shortId, string $newUrl ): ShortLinkResult;
    public function stats( string $shortId ): ?ShortLinkStats;  // if the vendor exposes it
}

final class BitlyProvider implements ShortLinkProvider {
    public function create( string $shortId, string $fullUrl ): ShortLinkResult {
        $res = $this->api( 'POST', '/v4/bitlinks', [
            'long_url'       => $fullUrl,
            'domain'         => $this->brandedDomain,               // our custom short domain
            'custom_bitlink' => "{$this->brandedDomain}/{$shortId}", // our ID as the back-half
        ] );

        // Bitly may SILENTLY fall back to a random back-half if ours is somehow
        // taken, instead of failing. Never accept that: it would break the
        // "same ID everywhere" invariant. Assert it returned exactly what we asked.
        if ( $res->backHalf() !== $shortId ) {
            throw new ShortLinkCollision( $shortId );  // caller re-mints and retries
        }
        return ShortLinkResult::ok( $res->link() );
    }
    // updateTarget(), stats() ...
}

Two things we confirmed against Bitly's own documentation before relying on them:

Custom back-halves are unique per branded domain, not globally. On our own short domain, any code that is unique in our database is automatically unique on Bitly, so our UNIQUE constraint is the single source of truth. No second uniqueness problem to manage.
Bitly links are case-sensitive, which is why our mixed-case alphabet is safe and why 9Kx2a and 9kX2A are different links.

The one trap, captured in the code above: if you request a custom back-half that is
already in use, Bitly may return a link with a random back-half rather than an
error. Accept that blindly and your database says 9Kx2a while Bitly serves
something else. The integration must assert the returned back-half matches the
requested one, and treat a mismatch as a collision.

While Bitly is the active front, our DynamoDB table is effectively write-only,
since the short domain points at Bitly and our resolver is never triggered. That is
not waste, it is a warm standby. Storing a few hundred bytes per link and doing the
occasional write costs almost nothing, and it is exactly what makes failover a DNS
change rather than a frantic rebuild.

The payoff: failover is a DNS change

Put it together and the failover story is almost boring, which is the point. The
short domain points at Bitly today. To take it back in-house, you repoint its DNS
to our CloudFront distribution. Every link already in the wild keeps working,
because the codes are identical on both fronts and our DynamoDB table already holds
every mapping.

The one operational honesty here: that cutover is only as fast as DNS lets it be,
and the TTL is a knob you manage, not a constant. In steady state, pointing at
Bitly with no change in sight, a normal TTL (say an hour) is fine; the record is
not changing, so there is nothing to propagate faster. The TTL only matters around
a switch. For a planned move off Bitly, lower it to 60 to 300 seconds a day or two
ahead (long enough for the old, higher TTL to age out everywhere), make the change,
then raise it back. If instead you want to be ready for an unplanned failover, say
Bitly itself goes down, keep the TTL permanently low as cheap insurance, since the
cost on modern anycast DNS is negligible. One caveat: some resolvers clamp very low
values, so do not go below about 60 seconds or treat the TTL as an absolute
guarantee.

With DNS control on your side, the short-link layer survives a vendor shutdown, a
price hike, a removed feature, or a full CMS re-platform. The links keep resolving
regardless.

The honest part: analytics

If the in-house resolver can do everything, why pay Bitly at all? Analytics. Bitly
gives a newsroom per-link click counts, geographic and referrer breakdowns, an
editor-friendly UI for creating and tracking links, and the bot-filtering that
makes those numbers trustworthy. That is real product work, and it is the reason to
buy rather than build.

Could you build it? Yes, and the edge resolver is the perfect place to tap, because
every redirect is already an event. There are two complementary ways to capture it:

Client-side, by having the redirect append a marker (UTM parameters) to the destination, so the analytics already on the article page (GA4, or newsroom tools like Chartbeat and Parse.ly) attribute the visit. This counts human readers and naturally excludes bots.
Server-side, by having the resolver send a GA4 Measurement Protocol event on each resolution, which counts every hit including the ones that never render a page, closer to how Bitly counts.

One correction worth making, since it is a common assumption: GA cannot read the
request headers of a redirect, and the redirect runs no JavaScript. The signal that
reaches your analytics is the marker parameter or the server-side event, not a
header.

So the honest line is not "GA cannot track short links." It can. The gap is that
matching Bitly's per-link dashboards, editor UI, and bot filtering is a product you
would own and maintain, and for many newsrooms paying for that polish is the right
call. We built the durable core so we are never locked in, and we let Bitly handle
the analytics, with our own edge waiting as the hot standby. Buy the convenience,
own the lifeline.

That is the whole shape of it: build the part that must never disappear, the
resolution and the mapping, buy the convenience layer on top, and keep them
interchangeable so a vendor decision is never an existential one. A short link your
newsroom shared years ago should still land tomorrow, no matter who is answering
the domain.

This is the kind of WordPress and AWS engineering our practice is
built on. If you run a publication that lives on social and cannot afford to lose
the links it has shared, let's talk.

The 200-byte trap: why WordPress core updates break Arabic URLs

Jaafar Abazid — Sun, 21 Jun 2026 12:47:31 +0000

You update WordPress on a quiet afternoon — a routine release, the kind you've
installed a hundred times. The dashboard says everything went fine. Then the
404s start: not a handful, but every long-headlined article in your archive, all
at once, all in Arabic.

Nothing in the update log mentions it. No plugin changed. And the cruel part:
the data that made those URLs work is already gone — shaved off inside a
database-upgrade routine that ran for a few milliseconds and reported success.
This isn't a freak accident or a broken plugin. It's three separate assumptions
baked into WordPress core, each hard-coding the same number — 200 — and
Arabic sites are almost uniquely exposed to all three. We hit this running
WordPress for Arabic newsrooms, the same high-traffic publishing we've written
about surviving breaking-news spikes.
We traced it to the exact lines in core and built a fix that survives every
future update. Here's the whole story.

Why Arabic URLs hit a wall English never does

WordPress stores a post's slug in the post_name column of wp_posts, and a
category or tag slug in the slug column of wp_terms. Both are VARCHAR(200)
by default — room for 200 characters, which for an English headline is generous.
"Everything you need to know about our new pricing" is barely fifty. You'd have
to write a paragraph to run out.

Arabic is a different arithmetic, because of what WordPress actually stores in
that column. It doesn't keep the raw Arabic text — it stores the
percent-encoded form, the same %XX sequence that travels in the URL. Take a
single word:

الذكاء  →  %d8%a7%d9%84%d8%b0%d9%83%d8%a7%d8%a1

Every Arabic letter is two bytes in UTF-8, and every byte becomes a
three-character %XX token. So one Arabic character costs about six characters
of column space. Do the division: VARCHAR(200) holds roughly 33 Arabic
characters. A normal news headline — "القبض على المتهمين في قضية الاحتيال
الإلكتروني" — blows past that before it's halfway done.

So Arabic publishers learn early to widen the columns:

ALTER TABLE wp_posts MODIFY post_name VARCHAR(1024) NOT NULL DEFAULT '';
ALTER TABLE wp_terms MODIFY slug      VARCHAR(1024) NOT NULL DEFAULT '';

VARCHAR(1024) holds about 170 Arabic characters — comfortable. Permalinks
resolve, the newsroom publishes, and the problem looks solved.

It isn't. It's about one-third solved — and the other two-thirds are waiting
for the next core update. (This isn't only an Arabic problem, either: any
non-Latin script that percent-encodes — Persian, Urdu, Hebrew, Greek — hits the
same wall. Arabic publishers just hit it first and hardest.)

The number 200 lives in three places, not one

Here's the insight that turns this from a recurring mystery into something you
can actually close out. WordPress hard-codes "200" in three independent
places, and widening the column only touches the first:

Layer	What it caps at 200	Does widening the column fix it?
1 — Storage	the column that physically stores the slug	Yes — but a core update silently undoes it
2 — Generation	every new slug, the moment it is created	No — it's PHP; needs a code override
3 — De-duplication	slugs that collide and need a numeric suffix	No — but this only fires on collisions

Your ALTER fixes Layer 1's storage. But Layer 2 means that even with a
1024-wide column, every new slug is still cut to 200 bytes before it's ever
saved — unless something on your site already overrode it. (If long Arabic
slugs save correctly for you today, a plugin, your theme, or a past developer
already patched Layer 2 — which means you have an undocumented dependency you
didn't know you were relying on.) And Layer 1, the storage you so carefully
widened, is exactly the one a core update quietly reverts. Let's take each in
turn.

Layer 1 — how a core update erases your column width

WordPress keeps a canonical description of its own database schema, and on every
major update it reconciles the live database against that description. The chain
is short and deterministic:

A new release bumps $wp_db_version in version.php.
On the next admin request, wp_upgrade() notices the bump and runs the database upgrade.
That calls make_db_current_silent(), which calls dbDelta( wp_get_db_schema() ).
wp_get_db_schema() is the canonical schema — and it says, verbatim:

post_name varchar(200) NOT NULL default '',
...
slug varchar(200) NOT NULL default '',

dbDelta() then runs a DESCRIBE on every live table, compares each column to
the canonical definition, and for any mismatch emits an ALTER TABLE … CHANGE COLUMN to "correct" it. Your post_name is VARCHAR(1024); the canonical says
VARCHAR(200); they don't match — so dbDelta dutifully issues a CHANGE COLUMN
back to 200, MySQL rebuilds the table, and every byte past the 200th is
discarded.

Here's the detail that makes it unrecoverable. Years ago, core added downsize
protection to dbDelta — but only for TEXT and BLOB columns (it was
Trac #36748, born from exactly
this kind of data loss). VARCHAR got no such guard. So a TEXT column is safe
from accidental shrinking; your VARCHAR(1024) slug column is not. dbDelta
shrinks it without hesitation, and restoring the column to 1024 afterwards brings
back the width but not the data — those bytes were handed to MySQL and
dropped.

That's why your fix keeps coming undone: always right after an update, always
silently. It isn't a bug aimed at you — it's core doing exactly what it was
designed to do, to a column you were never expected to change.

For accuracy: a separate routine, pre_schema_upgrade(), also runs hand-written
ALTERs, but those are version-gated to historic migrations and won't touch a
modern site's post_name. The reversion you're seeing is dbDelta.

The fix — don't repair the damage, prevent the shrink

The instinct is to write something that detects the reverted column and
re-widens it after each update. Resist it. By the time you can detect the shrink,
the data is already gone — you'd just be putting an empty wider column back over
truncated slugs. The only fix that actually saves the data is one that stops
the shrink from ever happening.

And core hands you the seam to do it. dbDelta exposes a filter,
dbdelta_create_queries, that receives the canonical CREATE TABLE statements
before they're compared to the live database. Rewrite the canonical
post_name varchar(200) to varchar(1024) in that filter, and dbDelta's idea of
"correct" now matches what's actually on disk. It sees no mismatch. It emits no
CHANGE COLUMN. There is nothing to truncate.

<?php
/**
 * Plugin Name: Arabic Slug Schema Guard (must-use)
 * Description: Keeps wp_posts.post_name and wp_terms.slug at VARCHAR(1024) across
 *              core DB upgrades, so long Arabic slugs are never truncated.
 *              Prevention-first: dbDelta never even tries to shrink them.
 */
defined( 'ABSPATH' ) || exit;

const SLUG_COLUMN_LEN = 1024;

// Rewrite the canonical schema dbDelta diffs against, so "desired" already
// equals the live 1024-wide column — no CHANGE COLUMN is ever emitted.
add_filter( 'dbdelta_create_queries', function ( $queries ) {
    global $wpdb;

    foreach ( array( $wpdb->posts => 'post_name', $wpdb->terms => 'slug' ) as $table => $column ) {
        if ( isset( $queries[ $table ] ) ) {
            $queries[ $table ] = preg_replace(
                '/(\b' . $column . '\s+varchar\()\s*200\s*(\))/i',
                '${1}' . SLUG_COLUMN_LEN . '${2}',
                $queries[ $table ]
            );
        }
    }
    return $queries;
} );

That single filter is the whole prevention story for Layer 1, and it's robust in
a way an after-the-fact repair can never be: it runs inside dbDelta, so it
covers every path that triggers a schema reconcile — the admin "database
update required" screen, background auto-updates, and wp core update-db on the
CLI alike.

Where this code lives matters as much as what it does. Put it in a must-use
plugin — a single .php file in wp-content/mu-plugins/ — not a regular
plugin. MU-plugins always load, can't be deactivated from the dashboard, and load
before the upgrade routine runs. And because a core update only ever replaces
wp-admin, wp-includes and the root PHP files — it never touches wp-content —
your guard is guaranteed to still be in place at the exact moment the upgrade
fires. A regular plugin could be deactivated the one time it mattered; don't bet
your archive on a toggle.

Layer 2 — stop new slugs truncating at birth

Prevention on the column keeps your existing slugs safe. But Layer 2 is still
cutting every new slug to 200 bytes at the moment of creation, inside
sanitize_title_with_dashes(). The relevant line, unchanged in current core, is:

$title = utf8_uri_encode( $title, 200 );

That function is attached to the sanitize_title filter, so you can cleanly swap
it for an identical copy that uses a larger byte budget:

// Layer 2: replace core's slug generator with a byte-for-byte copy whose only
// change is the encoding cap. The copy self-tests against core (see below), so a
// future core rewrite of this function is caught instead of drifting silently.
remove_filter( 'sanitize_title', 'sanitize_title_with_dashes' );
add_filter( 'sanitize_title', 'asg_sanitize_title_with_dashes', 10, 3 );

function asg_sanitize_title_with_dashes( $title, $raw_title = '', $context = 'display' ) {
    // … the body is line-for-line core, with one change:
    //     utf8_uri_encode( $title, 200 )  →  utf8_uri_encode( $title, 1000 )
    // 1000 leaves headroom under the 1024 column for a "-2" collision suffix.
}

Pick a sane budget — around 1000 bytes (≈ 160 Arabic characters) leaves room
under the column for the numeric suffix WordPress adds to resolve duplicates. You
don't want unlimited slugs; you want enough.

Layer 3 — _truncate_post_slug() — caps at 200 too, but it only runs when a slug
collides and needs a -2 suffix. For unique news headlines that almost never
fires, and it isn't filterable, so most sites can leave it alone. If you
genuinely need more than 200 bytes even on collisions, you take over uniqueness
through the pre_wp_unique_post_slug filter — an advanced case worth a footnote,
not a paragraph.

Keeping the fork honest

Copying a core function buys a maintenance debt: the day WordPress rewrites
sanitize_title_with_dashes(), your copy diverges — silently, which is the exact
failure mode we're trying to kill. Pinning the copy to a core version and re-diffing
by hand works right up until the release someone forgets to check, which on a
long-lived site is when, not if. So don't rely on remembering. Make the plugin
re-diff itself.

The lever: remove_filter() only unhooks the function — sanitize_title_with_dashes()
stays callable. So you can use core's own current code as a live oracle and assert
your fork still agrees with it on short inputs, where neither byte cap fires and
the only thing left that could differ is the cleanup logic:

// Run once per core version. Short fixtures => neither length cap engages,
// so any difference is pure logic drift, not the byte budget.
foreach ( array( 'الذكاء الاصطناعي', 'عاجل: «مهم» اليوم', 'foo/bar &mdash; baz' ) as $f ) {
    if ( sanitize_title_with_dashes( $f, $f, 'save' )
         !== asg_sanitize_title_with_dashes( $f, $f, 'save' ) ) {
        // core changed the cleanup logic — log + email ops, and (optionally) fall
        // back to core's generator so slugs cap at 200 again: degraded, but safe
        // and known, never a malformed slug from a stale copy.
    }
}

This beats a source-hash check on two counts. It's semantic, not textual — it
stays quiet when core only touches the length handling (which you override anyway)
and fires only when a change actually breaks your output, so the alerts that do
fire get acted on. And it degrades safely: on drift you fall back to core's exact
behaviour — worst case, new slugs cap at 200 until you re-sync, never a half-encoded
slug from a stale copy. Loud-and-safe beats silent-and-wrong. The full guard (with
the per-core-version cache and the optional fail-safe switch) is in the complete
plugin below.

A tripwire, because silent failure is the real enemy

The filter prevents the known incident. But the failure mode that actually hurt
you was that it happened silently — so the last piece is making sure you'd
never again learn about it from a drop in search traffic. The same MU-plugin can
verify the column widths after every update and shout if anything is wrong:

Hook upgrader_process_complete to flag that a core update just ran.
On the next admin request, check the real column widths in information_schema and, if either has shrunk, write to the error log and email ops.
Expose a WP-CLI command for cron-based monitoring:

# Nightly: verify the slug columns, email ops if either has reverted.
0 3 * * *  cd /var/www/site && wp asg verify | grep -q REVERTED \
           && wp asg verify | mail -s "WP slug schema reverted on $(hostname)" ops@example.com

One discipline to internalise: this tripwire restores confidence, not data.
If it ever reports a reverted column, treat it as an incident, not a self-healing
event — the slugs longer than the new width are already gone and must come back
from a backup. Prevention (the filter) and backups are your safety net; the
tripwire just tells you when to reach for them.

"Isn't VARCHAR(1024) dangerous?" — no, and the reason is reassuring

Widening these columns sounds risky — indexes, utf8mb4, InnoDB limits — and
it's the part people most often get scared off by. It's almost entirely a
non-issue, and one fact explains why:

The index on these columns is a fixed 191-character prefix, independent of
the column's declared length. Core defines KEY post_name (post_name(191)) — it
indexes the first 191 characters whether the column is 200 wide or 1024. Widening
the column doesn't enlarge the index by a single byte.

That dissolves the usual worries:

Index / InnoDB prefix limits. The old InnoDB prefix ceiling is 767 bytes; WordPress chose 191 because 191 × 4 (utf8mb4's worst case) = 764, just under it. Because the prefix stays at 191 no matter how wide the column grows, you never move towards that limit. (A quiet irony: slugs are stored as percent-encoded ASCII, so they were never going to hit four bytes per character anyway.)
Row size. VARCHAR stores the actual length of each value, not its declared maximum — a 30-character slug takes ~30 bytes in a VARCHAR(1024) exactly as it would in a VARCHAR(200). Rows don't get bigger because the ceiling moved up.
Query plans. Lookups use the same 191-prefix index to narrow, then verify the full value. Identical behaviour at 200 or 1024.
Plugins. SEO plugins, caches and CDNs read post_name and emit longer URLs without complaint.

The genuine risks aren't in steady state — they're tools that recreate the
schema from an old definition: a migration plugin that runs its own
CREATE TABLE, or, most commonly, restoring a SQL dump taken before you widened
the columns. A dump of the current database preserves VARCHAR(1024)
correctly; importing an old structure silently puts you back at 200. Write that
one down in your runbook.

Doing it safely on a site with millions of posts

There's one operational gotcha, and it's about the migration itself, not the
result. Going from VARCHAR(200) to VARCHAR(1024) cannot be an instant,
in-place change. InnoDB only keeps a VARCHAR length change "in place" while both
lengths stay in the same size class — values under 256 use one length byte,
values 256 and over use two. Crossing 255 forces ALGORITHM=COPY: a full table
rebuild. On a wp_posts with millions of rows, a raw ALTER means a long
operation and a problematic lock.

So on a large live site, do the initial widening with an online schema-change
tool, not a bare ALTER:

pt-online-schema-change \
  --alter "MODIFY post_name VARCHAR(1024) NOT NULL DEFAULT ''" \
  --chunk-time=0.5 --max-load Threads_running=50 \
  --execute D=wordpress,t=wp_posts

(gh-ost is an equally good triggerless alternative.) wp_terms is tiny and
takes a plain ALTER without ceremony; wp_posts is the one that needs the
online tool. The rollout that's bitten no one:

Back up, and confirm the dump shows VARCHAR(1024) afterwards.
Clone to staging, deploy the MU-plugin, and run a real major core update there. Confirm no CHANGE COLUMN appears and the verify command reports OK.
Deploy the MU-plugin to production before the next core update — prevention has to be in place ahead of the event it prevents.
Widen the production columns off-peak with pt-osc / gh-ost.
Add a nightly verify cron and a 404 monitor, so anything unexpected surfaces in hours, not in a month of lost rankings.
Keep the MU-plugin in version control, and never import a pre-widening structure dump.

The deeper fix — stop betting your URLs on a column width

Everything above makes Arabic slugs safe. But there's a more permanent way to
think about it, and for a large news archive it's worth the shift: don't let
the URL depend on the slug surviving at all.

Anchor your permalinks on the numeric post ID, and keep the Arabic slug as a
descriptive — but cosmetic — suffix:

https://example.com/123456/الذكاء-الاصطناعي

Resolve the post by its ID, and the slug becomes decoration. If it's ever
truncated, malformed, or edited, the URL still resolves to the right article
instead of 404-ing — and WordPress can 301 to the canonical form. You keep the
Arabic keywords in the URL for search relevance and you become structurally
immune to the entire class of problem. (If you want to stop touching core tables
altogether, you can go one step further and store the long slug in your own
indexed routing table, which dbDelta has no opinion about — but for most teams,
ID-anchored permalinks are the sweet spot.)

That's the difference between patching a bug and designing it out.

The complete plugin

Everything above, assembled into one must-use plugin. Drop it in
wp-content/mu-plugins/arabic-slug-schema-guard.php, widen the columns once with
an online schema-change tool, and all three layers — plus the tripwire — are
handled in a single place. The slug generator is a copy of core's
sanitize_title_with_dashes(); only the byte cap differs.

📦 Prefer it ready-made? The plugin is open-source on GitHub as mantekio/arabic-slug-schema-guard — or composer require mantekio/arabic-slug-schema-guard. Star it, file an issue, or lift it whole.

<?php
/**
 * Plugin Name: Arabic Slug Schema Guard (must-use)
 * Description: Keeps wp_posts.post_name and wp_terms.slug at VARCHAR(1024) across
 *              core DB upgrades, lets core generate long URL-encoded Arabic slugs,
 *              and verifies + alerts after every update. Prevention-first:
 *              dbDelta never truncates, because the canonical schema it diffs
 *              against already says 1024. The slug fork self-tests against core
 *              on each update and can fail safe.
 */
defined( 'ABSPATH' ) || exit;

const ASG_COLUMN_LEN = 1024;  // physical column width (bytes)
const ASG_SLUG_BYTES = 1000;  // max generated slug length, under the column width
const ASG_SCHEMA_SIG = 'post_name:1024;slug:1024';
// define( 'ASG_ALERT_EMAIL', 'ops@example.com' );  // optional, set in wp-config.php
// define( 'ASG_L2_FAILSAFE', true );               // optional: on Layer-2 drift, fall back to core (slugs cap at 200) until you re-sync

/* LAYER 1 — PREVENTION
 * Rewrite the canonical CREATE TABLE dbDelta diffs against, so "desired" already
 * equals the live 1024-wide column and no destructive CHANGE COLUMN is emitted. */
add_filter( 'dbdelta_create_queries', function ( $queries ) {
    global $wpdb;
    foreach ( array( $wpdb->posts => 'post_name', $wpdb->terms => 'slug' ) as $table => $column ) {
        if ( isset( $queries[ $table ] ) ) {
            $queries[ $table ] = preg_replace(
                '/(\b' . $column . '\s+varchar\()\s*200\s*(\))/i',
                '${1}' . ASG_COLUMN_LEN . '${2}',
                $queries[ $table ]
            );
        }
    }
    return $queries;
} );

/* LAYER 2 — GENERATION
 * Core caps new slugs at 200 bytes via utf8_uri_encode($title, 200). Swap in a
 * copy of sanitize_title_with_dashes() whose only change is the byte budget.
 * Installed conditionally: if the drift guard (below) flagged THIS core version
 * and ASG_L2_FAILSAFE is on, stay on core's default (caps at 200 — degraded but
 * safe and known) rather than run a fork we know has drifted. */
if ( get_option( 'asg_l2_status' ) === 'drift:' . $GLOBALS['wp_version']
     && defined( 'ASG_L2_FAILSAFE' ) && ASG_L2_FAILSAFE ) {
    // Known-drifted on this core version → leave core's generator in place.
} else {
    remove_filter( 'sanitize_title', 'sanitize_title_with_dashes' );
    add_filter( 'sanitize_title', 'asg_sanitize_title_with_dashes', 10, 3 );
}

function asg_sanitize_title_with_dashes( $title, $raw_title = '', $context = 'display' ) {
    $title = strip_tags( $title );
    // Preserve already-encoded octets through the cleanup below.
    $title = preg_replace( '|%([a-fA-F0-9][a-fA-F0-9])|', '---$1---', $title );
    $title = str_replace( '%', '', $title );
    $title = preg_replace( '|---([a-fA-F0-9][a-fA-F0-9])---|', '%$1', $title );

    if ( seems_utf8( $title ) ) {
        if ( function_exists( 'mb_strtolower' ) ) {
            $title = mb_strtolower( $title, 'UTF-8' );
        }
        $title = utf8_uri_encode( $title, ASG_SLUG_BYTES );  // core hard-codes 200 here
    }

    $title = strtolower( $title );

    if ( 'save' === $context ) {
        // Turn non-breaking spaces, en/em dashes and slashes into hyphens.
        $title = str_replace( array( '%c2%a0', '%e2%80%93', '%e2%80%94' ), '-', $title );
        $title = str_replace( array( '&nbsp;', '&#160;', '&ndash;', '&#8211;', '&mdash;', '&#8212;' ), '-', $title );
        $title = str_replace( '/', '-', $title );
    }

    $title = preg_replace( '/&.+?;/', '', $title );          // strip remaining entities
    $title = str_replace( '.', '-', $title );
    $title = preg_replace( '/[^%a-z0-9 _-]/', '', $title );  // keep only slug-safe chars
    $title = preg_replace( '/\s+/', '-', $title );
    $title = preg_replace( '|-+|', '-', $title );
    return trim( $title, '-' );
}

/* LAYER 2 DRIFT GUARD — self-test the fork against core's live implementation.
 * remove_filter() only unhooks sanitize_title_with_dashes(); the function stays
 * callable, so we use core's CURRENT code as a live oracle and assert our fork
 * still agrees on SHORT inputs (where neither byte cap engages — the only thing
 * the fork changed). Any divergence == core altered the cleanup logic and our
 * copy has drifted. Runs once per core version; shouts, and can fail safe. */
add_action( 'admin_init', 'asg_guard_layer2_drift' );

function asg_guard_layer2_drift() {
    $ok      = 'ok:' . $GLOBALS['wp_version'];
    $drifted = 'drift:' . $GLOBALS['wp_version'];
    if ( in_array( get_option( 'asg_l2_status' ), array( $ok, $drifted ), true ) ) {
        return;  // already settled for this core version
    }
    if ( ! function_exists( 'sanitize_title_with_dashes' ) ) {
        return;  // core refactored it away — no oracle to diff against; the fork
                 // still runs as a standalone copy (it needs no removed function).
    }

    // Deliberately SHORT fixtures so neither length cap fires — any difference is
    // pure cleanup-logic drift, not the byte budget.
    $fixtures = array(
        'الذكاء الاصطناعي',
        'عاجل: تطورات «مهمة» اليوم',
        'Mixed عربي + English — dash',
        'foo/bar &mdash; baz',
        'UPPER   multiple   spaces',
        '%d8%a7 pre-encoded octet',
    );

    $drift = array();
    foreach ( $fixtures as $f ) {
        $core = sanitize_title_with_dashes( $f, $f, 'save' );
        $ours = asg_sanitize_title_with_dashes( $f, $f, 'save' );
        if ( $core !== $ours ) {
            $drift[] = "in=[{$f}] core=[{$core}] ours=[{$ours}]";
        }
    }

    if ( $drift ) {
        $msg = "[Arabic Slug Schema Guard] Layer-2 DRIFT on WP {$GLOBALS['wp_version']}: core "
             . "sanitize_title_with_dashes() no longer matches our fork — re-sync the copy.\n"
             . implode( "\n", $drift );
        error_log( $msg );
        if ( defined( 'ASG_ALERT_EMAIL' ) && function_exists( 'wp_mail' ) ) {
            wp_mail( ASG_ALERT_EMAIL, 'WP slug Layer-2 drift: ' . wp_parse_url( home_url(), PHP_URL_HOST ), $msg );
        }
        update_option( 'asg_l2_status', $drifted, true );  // autoload — the fail-safe reads it every request
        return;  // do NOT cache "ok" while drifted
    }
    update_option( 'asg_l2_status', $ok, true );
}

/* LAYER 3 — DE-DUPLICATION (optional)
 * _truncate_post_slug() also caps at 200, but only when a slug COLLIDES and needs
 * a "-2" suffix — rare for unique headlines, and it isn't filterable. If you need
 * >200 bytes even on collisions, take over uniqueness here. Most sites skip this.
 *
 * add_filter( 'pre_wp_unique_post_slug', 'asg_unique_post_slug', 10, 6 );
 */

/* TRIPWIRE — verify + alert after every core update
 * This only detects and alerts: it restores the COLUMN, never bytes already
 * truncated. Treat any revert as an incident — restore from backup. */
add_action( 'upgrader_process_complete', function ( $upgrader, $extra ) {
    if ( isset( $extra['type'] ) && 'core' === $extra['type'] ) {
        delete_option( 'asg_schema_sig' );  // force a re-check on the next admin_init
    }
}, 10, 2 );

add_action( 'admin_init', function () {
    if ( get_option( 'asg_schema_sig' ) === ASG_SCHEMA_SIG ) {
        return;  // fast path: already verified since the last update
    }
    $reverted = asg_reverted_columns();
    if ( $reverted ) {
        $msg = '[Arabic Slug Schema Guard] Column(s) reverted: ' . implode( ', ', $reverted )
             . '. Long slugs were truncated — restore from backup and check 404 logs.';
        error_log( $msg );
        if ( defined( 'ASG_ALERT_EMAIL' ) ) {
            wp_mail( ASG_ALERT_EMAIL, 'WP slug schema reverted: ' . wp_parse_url( home_url(), PHP_URL_HOST ), $msg );
        }
        return;  // do NOT cache "ok" while broken
    }
    update_option( 'asg_schema_sig', ASG_SCHEMA_SIG, false );
} );

function asg_reverted_columns() {
    global $wpdb;
    $reverted = array();
    foreach ( array( array( $wpdb->posts, 'post_name' ), array( $wpdb->terms, 'slug' ) ) as list( $table, $column ) ) {
        $len = (int) $wpdb->get_var( $wpdb->prepare(
            "SELECT CHARACTER_MAXIMUM_LENGTH FROM information_schema.COLUMNS
              WHERE TABLE_SCHEMA = %s AND TABLE_NAME = %s AND COLUMN_NAME = %s",
            DB_NAME, $table, $column
        ) );
        if ( $len && $len < ASG_COLUMN_LEN ) {
            $reverted[] = "{$table}.{$column} (now {$len})";
        }
    }
    return $reverted;
}

/* WP-CLI — `wp asg verify` for cron-based monitoring */
if ( defined( 'WP_CLI' ) && WP_CLI ) {
    WP_CLI::add_command( 'asg verify', function () {
        foreach ( asg_reverted_columns() ?: array( 'ok' ) as $row ) {
            WP_CLI::log( 'ok' === $row ? 'Schema OK — both columns at VARCHAR(1024).' : "REVERTED: {$row}" );
        }
    } );
}

This is the kind of problem that never shows up in a tutorial. It lives where
WordPress internals, MySQL's storage rules, Arabic character encoding and SEO all
overlap, and it only reveals itself at the worst possible moment. It's also the
territory we work in every day — keeping Arabic publishing fast, multilingual and
unbreakable on WordPress, right through to AWS at scale.

If you run a WordPress publication in Arabic and want it to survive its own
updates, let's talk.

How we built mantek.io for the price of a domain

Jaafar Abazid — Tue, 16 Jun 2026 23:43:33 +0000

The site you're reading costs us almost nothing to run. There's no server invoice, no hosting bill, no monthly platform fee — just the domain name, renewed once a year. Everything else runs on infrastructure that's free at our scale and fast everywhere in the world.

That isn't a corner we cut. It's a set of deliberate choices — static output, edge delivery, git as the backbone — that happen to be cheaper and faster and simpler than the alternative. Here's the whole stack, and the thinking behind it.

The whole bill is the domain

Take the site apart and look for the costs, and there's only one line item.

Hosting and CDN: nothing. The site lives on Cloudflare Pages, which serves it from data centres in hundreds of cities, with unlimited bandwidth on the free tier. The thing that usually costs the most — global delivery — costs zero here.
DNS: nothing. Managed on Cloudflare alongside the domain.
Email Sending: nothing. Contact-form mail goes through Resend's free tier.
The domain: the only invoice. Renewed yearly, and that's the entire running cost.

The infrastructure is free; the engineering is the investment. That's the trade — and for a site that has to be fast, bilingual and maintainable for years, it's the right one.

Static output, Git as the pipeline

The site is built with Astro and compiled to plain HTML and CSS. There's no application server running in the background — nothing to patch, scale, or wake up when a visitor arrives. Cloudflare serves the finished files from the edge location nearest each reader, which is why pages feel instant.

Deployment is just git. We push to the main branch; Cloudflare builds the site and publishes it worldwide in a minute or less. Every branch gets its own preview URL, so a change can be reviewed on a real address before it goes live. And because the repository is the source of truth, undoing a bad change is a git revert — not a 2 a.m. restore from backup.

A CMS with no database

This blog is editable in the browser, but there's no database behind it and no CMS server to keep alive. The editor is git-based: saving a post commits a Markdown file to the repository and rides the same automatic deploy as the code.

That has quiet benefits. Every edit is versioned like code, with full history. There's no database to back up, secure, or migrate. The editor sits behind GitHub sign-in, so there's no separate set of passwords to manage and very little for a scanner to find. Content and code live in one place, and ship the same way.

A contact form without a back end

A contact form normally means a server somewhere waiting to receive it. Ours is a single serverless function that runs at the edge, on demand: it validates the submission and hands it to Resend, which sends the email. No always-on back end, no queue, no infrastructure to maintain between messages.

The credentials never touch the codebase. The Resend API key lives in Cloudflare's encrypted environment variables, read by the function at run time — it isn't in the repository and isn't in the published site. Spam is caught with a hidden honeypot field and server-side checks rather than a third-party CAPTCHA. And the form degrades gracefully: with JavaScript switched off it submits natively and returns a thank-you page; with JavaScript on it posts in the background and shows inline status. No cookies, either way.

Chasing a perfect score

A static site is a fast start, not a finished one. Getting to a perfect Lighthouse score — 100 across Performance, Accessibility, Best Practices and SEO — took a series of small, deliberate decisions:

Self-hosted fonts, preloaded. The fonts are served from our own domain, not a third-party font CDN, and the one the headline renders in is preloaded so it's ready for the first paint. The Arabic typeface only downloads on Arabic pages.
No render-blocking JavaScript. What little script the site needs is inlined and tiny; there's no framework runtime shipping to the browser. These are HTML pages with a few grams of JavaScript, not an app pretending to be a page.
One shared stylesheet. The CSS is a single file, cached across every page, so moving around the site re-downloads nothing.
Work the browser can skip. Sections below the fold are marked so the browser doesn't spend layout effort on them until they're about to be seen.
No flash, no shift. The colour theme is resolved before the first paint, so nothing flickers from light to dark or jumps around as it loads.

None of these is dramatic on its own. Together they're the difference between "fast enough" and a perfect score.

Cached hard, but never stale

Speed and freshness usually pull against each other; the right caching rules give you both. Build assets get fingerprinted filenames, cached for a year and marked immutable — the browser never asks about them again. Images are cached for a week. But the HTML itself is always revalidated, so the moment we publish, every reader sees the new version.

The one lesson worth passing on: immutable means exactly that. It belongs only on files whose name changes when their contents do. Put it on a stable URL and you'll spend a day fighting your own cache.

Secure and findable by default

A set of security headers is applied at the edge, for free: strict HTTPS (HSTS), protection against clickjacking and MIME-sniffing, a conservative referrer policy, and a permissions policy that switches off the camera, microphone and location access the site never uses. There's one canonical hostname; everything else redirects to it.

Findability is built in the same spirit. Every page declares its canonical URL and its English/Arabic alternates, so search engines read the two languages as one site rather than duplicate content. Each post generates its own social-share card. Structured data, an auto-generated sitemap and an RSS feed ship on every build. And the analytics are cookieless — which means no consent banner slowing the page down or greeting the reader with a pop-up.

Two languages, one build

The site is fully bilingual: English at the root, Arabic — right-to-left — under /ar/. There's no duplicate site and no translation plugin. The same components render both languages from a dictionary, down to mirrored layouts and translated structured data. Adding a language is additive, not a rebuild.

If you're building something similar

Default to static. If a page can be HTML, it should be. Everything downstream — speed, cost, security — gets easier.
Make git the backbone. Deploys, content, rollbacks and history in one place beats four systems that have to be kept in sync.
Spend the savings on judgement. Free infrastructure frees the budget for the part that actually matters — the engineering.

This is the same discipline we bring to client work: systems that are fast, cheap to run, and built to last. If you'd like a site that behaves like this one, see what we do or start a conversation.