DEV Community: rokya elbarbary

Test Your Redirect Map Before and After a Site Migration With a Small Python Script

rokya elbarbary — Tue, 29 Sep 2026 14:23:49 +0000

Most site migrations do not fail at launch. They fail quietly over the following weeks, as old URLs that used to earn traffic and links start returning 404s, land on the homepage, or bounce through three redirects before reaching the right page.

The fix is boring and reliable: keep a redirect map, and test it automatically before and after launch. This post gives you a small standard-library Python script that does exactly that.

What the script checks

For every row in a CSV of old_url,expected_url it follows redirects one hop at a time and reports:

Verdict	Meaning
`OK`	One permanent redirect (301/308), or none, ending on the expected URL with HTTP 200
`WRONG_TARGET`	The chain ends on a 200 page, but not the one you mapped (often the homepage)
`CHAIN`	More than one redirect before the final page - fix the map so old URLs go straight to the destination
`TEMPORARY`	The only redirect is a 302/303/307 - fine for campaigns, usually wrong for a migration
`LOOP`	A redirect loop or more than 10 hops
`ERROR`	A 4xx/5xx or a network error at the end of the chain

Following hops manually matters: if you let your HTTP client follow redirects automatically, you only see the final URL and miss chains and temporary redirects.

The script

#!/usr/bin/env python3
"""Check a redirect map after a site migration.

Input: a CSV with two columns, old_url,expected_url (header row required).
Output: one line per row: OK / WRONG_TARGET / CHAIN / LOOP / ERROR, plus the hops taken.
Standard library only.
"""
import csv
import sys
import urllib.error
import urllib.request
from urllib.parse import urljoin

MAX_HOPS = 10


class NoRedirect(urllib.request.HTTPRedirectHandler):
    def redirect_request(self, req, fp, code, msg, headers, newurl):
        return None  # do not follow; we record each hop ourselves


OPENER = urllib.request.build_opener(NoRedirect)


def hops_for(url):
    """Return a list of (status, url) pairs, following redirects one hop at a time."""
    hops, seen = [], set()
    while len(hops) < MAX_HOPS:
        if url in seen:
            hops.append(("LOOP", url))
            return hops
        seen.add(url)
        req = urllib.request.Request(url, method="HEAD", headers={"User-Agent": "redirect-check/1.0"})
        try:
            with OPENER.open(req, timeout=15) as resp:
                hops.append((resp.status, url))
                return hops
        except urllib.error.HTTPError as e:
            hops.append((e.code, url))
            location = e.headers.get("Location")
            if e.code in (301, 302, 303, 307, 308) and location:
                url = urljoin(url, location)
                continue
            return hops
        except (urllib.error.URLError, TimeoutError) as e:
            hops.append(("ERROR", f"{url} ({e})"))
            return hops
    hops.append(("TOO_MANY", url))
    return hops


def classify(hops, expected):
    last_status, last_url = hops[-1]
    redirects = [h for h in hops if h[0] in (301, 302, 303, 307, 308)]
    if last_status in ("LOOP", "TOO_MANY"):
        return "LOOP"
    if last_status == "ERROR" or last_status != 200:
        return "ERROR"
    if last_url.rstrip("/") != expected.rstrip("/"):
        return "WRONG_TARGET"
    if len(redirects) > 1:
        return "CHAIN"
    if redirects and redirects[0][0] != 301 and redirects[0][0] != 308:
        return "TEMPORARY"
    return "OK"


def main(path):
    problems = 0
    with open(path, newline="", encoding="utf-8") as f:
        for row in csv.DictReader(f):
            hops = hops_for(row["old_url"].strip())
            verdict = classify(hops, row["expected_url"].strip())
            problems += verdict != "OK"
            trail = " -> ".join(f"{status} {url}" for status, url in hops)
            print(f"{verdict:13} {trail}")
    print(f"\n{problems} problem(s) found")
    return 1 if problems else 0


if __name__ == "__main__":
    sys.exit(main(sys.argv[1]))

Running it

Create redirects.csv:

old_url,expected_url
http://example.com/seo,https://example.com/seo
http://example.com/services/seo,https://example.com/seo
https://example.com/blog/old-post,https://example.com/blog/new-post

Then:

python redirect_check.py redirects.csv

Sample output (illustrative):

OK            301 http://example.com/seo -> 200 https://example.com/seo
CHAIN         301 http://example.com/services/seo -> 301 https://example.com/services/seo -> 200 https://example.com/seo
ERROR         404 https://example.com/blog/old-post

2 problem(s) found

The script exits with code 1 when anything is wrong, so you can drop it into CI and fail a deployment that breaks the redirect map.

Where the redirect map comes from

Export every URL that currently gets organic traffic or has backlinks (Search Console, analytics landing pages, your crawler of choice, backlink exports).
Map each one to the closest equivalent new page. Only fall back to a parent category when there is genuinely no equivalent; mass-redirecting everything to the homepage is treated like a soft 404.
Remove pages you are intentionally retiring from the map and let them return 404 or 410.

Before and after launch

Before: run it against staging (swap the hostnames in the CSV) and fix every non-OK line.
Launch day: run it against production immediately after DNS or routing changes.
Weeks 1-4: run it on a schedule and watch Search Console for 404 spikes and "Page with redirect" reports.
Update internal links so they point straight at the new URLs instead of relying on redirects.

Limitations

It uses HEAD requests; a few servers answer HEAD differently from GET. If you see odd 405 errors, change method="HEAD" to "GET".
It does not execute JavaScript, so client-side redirects are not detected - which is also a good reason not to rely on them for migrations.
Keep request volume polite on large maps (add a small delay or run it in batches).

Written by the team at Gorilla Vibe, a GCC-focused marketing-as-a-service agency. The script is standard library only; copy it, adapt it, and use it freely.

A Content Brief Template for Writers, Editors and SEOs

rokya elbarbary — Tue, 29 Sep 2026 14:12:51 +0000

A content brief is the contract between the person who knows why a piece should exist and the person who writes it. Without one, writers guess at intent, editors rewrite for tone, and the finished article ranks for nothing and converts nobody.

The template below works for blog articles, guides and landing page copy. Fill in every section; if a section cannot be filled, the piece is probably not ready to commission.

Content brief

Working title: " [title]"
Owner / approver: [name]
Writer: [name]
Due date: [YYYY-MM-DD]
Target URL: [final URL or planned slug]

1. Purpose

One sentence: what should this piece achieve for the business?

Example: Help founders understand what a marketing audit covers, so that qualified prospects book an audit call.

2. Reader

Describe the reader by situation, not just job title.

Example: A founder of a 20-person company whose ad spend has grown but whose lead volume has not, who suspects money is being wasted but does not know where.

What do they already know? What do they need to believe or understand by the end?

3. Search intent

Question	Answer
Primary query or topic	[e.g. "digital marketing audit"]
Intent type	Informational / Commercial investigation / Transactional / Navigational
What currently ranks?
What is missing from those results?

If the results are dominated by a format you are not planning to write (for example, tools or product pages), reconsider the format.

4. Outline

Provide H2s (and H3s where useful) in order. Mark sections that need input from a subject-matter expert.

[H2]
[H2]
[H2]
FAQ (only questions real customers ask)

5. Evidence and sources

Primary sources the writer must use (official documentation, first-party data, interviews).
Claims that must not be made without proof (percentages, guarantees, client names).
Statistics: include only if the original source can be linked. Otherwise leave them out.

6. Internal links

Anchor idea	Destination	Why
[natural phrase]	[related guide]	Supports a concept the reader needs
[natural phrase]	[relevant service page]	Next step for readers who want help

Keep links useful: one or two relevant service links in a helpful guide are fine; a link in every paragraph is not.

7. Format and style

Target length: set by what the topic needs, not a word count target.
Tone: [e.g. direct, practical, no jargon without explanation]
Language/market: [e.g. English for GCC readers; an Arabic version to follow]
Visuals needed: [diagrams, screenshots, tables]

8. Call to action

What should the reader do next, and where on the page?

9. Definition of done

[ ] Answers the primary question within the first few paragraphs
[ ] Every claim is sourced or removed
[ ] Title, meta description and H1 written and unique
[ ] Internal links added and checked
[ ] Reviewed by the subject-matter expert
[ ] Proofread by a second person

Using the brief after publishing

Keep the brief with the published URL. Three months later, compare the page's actual search queries and conversions against the purpose and intent you wrote down - that comparison tells you whether to update, consolidate or leave the page alone.

A Webhook Runbook for Marketing Automation That Never Loses a Lead

rokya elbarbary — Tue, 29 Sep 2026 14:05:24 +0000

A typical lead journey now crosses several systems: a website form, an automation tool, a CRM, a messaging channel and sometimes a spreadsheet. Webhooks glue them together, and when a webhook silently fails, a real enquiry disappears. This runbook describes how to design those integrations so failures are rare, visible and recoverable.

1. Map the flow before building it

Write the journey as a table first:

Step	Source system	Event	Destination	Payload owner
1	Website form	Form submitted (server confirmed)	Automation tool webhook	Web team
2	Automation tool	New lead	CRM - create or update contact	Marketing ops
3	CRM	Lead assigned	Sales notification channel	Sales ops
4	CRM	Lead qualified	Ad platform offline conversion upload	Marketing ops

Every row needs an owner who is responsible when that step breaks.

2. Design the payload

Include a unique event ID generated at the source (for example a UUID per form submission). Every downstream step should carry it.
Include a timestamp in UTC and the source (form ID, page URL).
Send only the fields the destination needs. Personal data you do not transmit cannot leak.
Version the payload ("schema_version": 2) so you can change it without breaking consumers.

3. Make every receiver idempotent

Webhook senders retry. Networks duplicate requests. If the same payload arrives twice, the receiver must not create two contacts or send two welcome messages.

Store processed event IDs and ignore repeats.
Prefer upsert (create or update by email or external ID) over blind create.

4. Handle failure deliberately

Situation	Behaviour
Destination returns 5xx or times out	Retry with exponential backoff (for example after 1, 5, 15 and 60 minutes)
Destination returns 4xx (bad request)	Do not retry blindly - send to a dead-letter queue and alert
Destination rate-limits (429)	Respect `Retry-After`; slow down
All retries exhausted	Dead-letter queue + alert to the step owner

A dead-letter queue can be as simple as a table or sheet that stores failed payloads with the error message, so they can be replayed after the fix.

5. Secure the endpoints

Verify a signature (HMAC of the payload with a shared secret) on incoming webhooks when the sender supports it.
Keep secrets in the automation tool's credential store or environment variables - never inside a shared document or a workflow description.
Reject payloads older than a few minutes to limit replay attacks, if timestamps are signed.
Use HTTPS only.

6. Monitor what matters

Volume check: alert if form submissions arrive on the website but no leads are created in the CRM for a defined period during business hours.
Error rate: alert on any dead-letter entry.
Reconciliation: once a week, compare form submission counts against CRM lead counts for the same period. Differences reveal silent failures.

7. Change management

Test changes in a sandbox or with a test form before touching the production flow.
Keep a changelog of workflow edits: date, who, what, why.
After any change, submit a real test lead end-to-end and confirm it arrives everywhere it should.

8. Incident checklist

Identify the first failing step using the event ID.
Pause downstream steps that could make things worse (for example automated messages).
Fix the cause.
Replay dead-letter payloads in order.
Confirm with the reconciliation check and write a short incident note.

A CRO Experiment Brief Template That Stops False Wins

rokya elbarbary — Tue, 29 Sep 2026 13:58:06 +0000

Most failed A/B tests fail before they launch: the hypothesis was vague, the metric was chosen afterwards, or the test was stopped the moment the dashboard turned green. A one-page brief, completed and agreed before anything is built, prevents all three.

Copy the template below into your ticket system or experiment log.

Experiment brief

ID: EXP-<number>
Owner: [name]
Status: Draft / Approved / Running / Concluded

1. Observation

What did you see, and where did you see it? Link the evidence.

Example: Session recordings and form analytics show that a large share of mobile visitors who open the quote form abandon it at the "company size" field.

Evidence sources can include analytics funnels, heatmaps, session recordings, on-site surveys, support tickets and usability tests. An opinion in a meeting is not an observation.

2. Hypothesis

Use this structure:

Because we observed [observation],
we believe that [change]
for [audience / segment]
will cause [expected behaviour change].
We will know this when [primary metric] changes in [direction].

3. Metrics

Type	Metric	Definition
Primary (one only)	e.g. quote form completion rate	Completed quote forms / sessions that viewed the form
Guardrail	e.g. lead quality	Share of leads accepted by sales
Guardrail	e.g. page performance	No regression in LCP or INP on the tested template
Secondary (diagnostic)	e.g. field-level drop-off	Not used to call the result

Decide the primary metric before launch. Reporting whichever metric happened to move afterwards is how false wins get shipped.

4. Design

Variants: Control vs.
Audience and targeting: device, market, language, traffic source
Traffic split: usually 50/50
Unit of randomisation: user (preferred) or session

5. Sample size and duration

Estimate the required sample with a calculator, using your current baseline conversion rate and the smallest effect worth detecting for the business.
Run for whole weeks (at least one, usually two or more full business cycles) to avoid day-of-week bias.
If the traffic needed exceeds what the page receives in a reasonable time, do not run the test. Use qualitative research or make the change based on evidence instead.

6. Stopping rule

Write it down: "We will stop when each variant reaches [n] visitors and at least [x] full weeks have passed." Do not stop early because a result looks significant on day three - repeated peeking inflates false positives unless your tool uses a method designed for it.

7. QA checklist before launch

[ ] Variant renders correctly on mobile and desktop, in every language the page supports
[ ] No flicker of the original content before the variant loads
[ ] Analytics events fire identically in both variants
[ ] The test does not break forms, checkout or consent banners
[ ] Exclusion rules work (internal traffic, bots)

8. Result and decision

Field	Entry
Outcome	Win / Loss / Inconclusive
Primary metric result	[effect and confidence interval]
Guardrails	[any regressions]
Decision	Ship / Iterate / Discard
What we learned	[one or two sentences, regardless of outcome]

Keeping a learning log

Store every concluded brief - including losses and inconclusive tests - in one searchable place. Over time the log becomes the most valuable CRO asset you own: it stops the team re-running the same idea and shows which kinds of changes actually move your audience.

A Bilingual Arabic/English (RTL + LTR) UX Checklist for Web Teams

rokya elbarbary — Tue, 29 Sep 2026 13:49:40 +0000

Sites that serve the Gulf and the wider Arabic-speaking market often need to work equally well in Arabic (right-to-left) and English (left-to-right). Mirroring the English layout is not enough: typography, forms, icons, numbers and search annotations all need attention. This checklist is meant for designers, developers and QA testers working on the same release.

Document and layout

[ ] Set lang and dir on the <html> element: <html lang="ar" dir="rtl"> for Arabic pages, <html lang="en" dir="ltr"> for English.
[ ] Use CSS logical properties (margin-inline-start, padding-inline-end, inset-inline-start, text-align: start) instead of left and right, so one stylesheet works in both directions.
[ ] Flex and grid layouts follow the writing direction automatically; check any component that uses absolute positioning or transforms.
[ ] Mixed-direction strings (an English brand name inside an Arabic sentence, a phone number, a URL) are wrapped in elements with dir="auto" or use <bdi> where the direction is unknown.

Typography

[ ] Choose an Arabic typeface designed for screen use and test it at body sizes, not only in headlines.
[ ] Arabic text usually needs a larger font size and line height than Latin text to be equally readable; do not reuse English values blindly.
[ ] Do not apply letter-spacing to Arabic - it breaks the connected script.
[ ] Avoid all-caps styling rules that only make sense for Latin scripts.
[ ] Check that text truncation (text-overflow: ellipsis) works from the correct side.

Icons and imagery

[ ] Mirror directional icons: back/forward arrows, chevrons in breadcrumbs, progress indicators, "send" icons.
[ ] Do not mirror icons that represent real-world objects or universal symbols: play buttons, clocks, checkmarks, logos, media controls.
[ ] Carousels and sliders move in the reading direction; swipe gestures match.
[ ] Photographs with text or directional composition may need separate crops, not a flipped image.

Forms

[ ] Labels, help text and error messages align to the start edge.
[ ] Inputs that hold Latin-only data (email, URL, some IDs) can be set to dir="ltr" so characters do not appear reversed while typing.
[ ] Phone inputs accept both Western Arabic (0-9) and Eastern Arabic (٠-٩) digits, or clearly state which is expected - and the backend normalises them.
[ ] Validation messages are translated, not just the labels.
[ ] Date pickers respect the locale's first day of the week and reading direction.

Numbers, dates and currency

[ ] Decide deliberately whether Arabic pages display Western Arabic or Eastern Arabic numerals, and apply it consistently. Use Intl.NumberFormat and Intl.DateTimeFormat with the right locale rather than hand-built strings.
[ ] Currency symbols and codes (AED, SAR, QAR, KWD, BHD, OMR) appear in the position readers expect for the locale.

Content and navigation

[ ] The language switcher is visible on every page, labelled in the target language ("English" / "العربية"), and links to the equivalent page, not the homepage.
[ ] Translations are written or reviewed by a native speaker, and adapted for the market - not machine-translated and published.
[ ] Navigation order reads correctly from the start edge.

Search and metadata

[ ] Each language version has its own URL (for example /ar/... and /en/...), its own title and meta description, and a self-referencing canonical.
[ ] hreflang annotations link each language version to the others and back to itself, and include x-default if there is a language selector page.
[ ] Structured data on Arabic pages is written in Arabic where it describes visible content.

QA pass

Test every key template in both languages on a real mobile device, with long real-world strings (long names, long company names, mixed Arabic/English addresses). Most RTL bugs only appear with real content.

Core Web Vitals Explained for the Marketers on Your Team

rokya elbarbary — Tue, 29 Sep 2026 13:12:40 +0000

Core Web Vitals are Google's three user-experience metrics for loading, responsiveness and visual stability. They matter for two reasons: they are part of the page experience signals Google Search considers, and - more importantly - they describe whether real visitors can actually use your pages.

This guide explains each metric in plain language, how to measure it, and where fixes usually come from.

The three metrics

Metric	Measures	"Good" threshold (Google)
LCP - Largest Contentful Paint	How long until the main content (usually a hero image or headline) is visible	2.5 seconds or less
INP - Interaction to Next Paint	How quickly the page responds visually after a tap, click or key press	200 milliseconds or less
CLS - Cumulative Layout Shift	How much content unexpectedly jumps around while loading	0.1 or less

Google assesses each metric at the 75th percentile of real page loads, separately for mobile and desktop. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024.

Field data vs lab data

Field data comes from real Chrome users (the Chrome User Experience Report, shown in Search Console and PageSpeed Insights). This is what counts.
Lab data comes from a simulated test (Lighthouse). It is repeatable and good for debugging, but it cannot measure INP directly and it does not reflect your real users' devices and networks.

A page can score well in Lighthouse and still fail in the field, usually on mid-range Android phones on mobile networks.

Where LCP problems usually come from

Slow server response (TTFB). Uncached HTML, slow APIs during server rendering, or no CDN close to your users.
The LCP image is discovered late. For example, a hero image set as a CSS background or injected by JavaScript. Put it in the HTML as an <img> and consider fetchpriority="high".
The LCP image is lazy-loaded. Never apply loading="lazy" to the above-the-fold hero.
Oversized images. Serve responsive sizes (srcset) and modern formats.
Render-blocking CSS and fonts. Inline critical CSS; use font-display: swap or optional.

Where INP problems usually come from

Long JavaScript tasks on the main thread - large bundles, heavy hydration, third-party scripts.
Tag manager bloat. Every chat widget, heatmap and pixel adds main-thread work. Audit tags quarterly and remove what nobody uses.
Expensive event handlers that do layout-heavy work synchronously. Yield to the main thread and defer non-urgent work.

Where CLS problems usually come from

Images and videos without width and height (or an aspect-ratio).
Late-loading banners, cookie bars or promos that push content down instead of overlaying it.
Web fonts that swap and change text size; match fallback font metrics.
Ads or embeds inserted without reserved space.

A workable process for marketing teams

Open the Core Web Vitals report in Search Console and group failing URLs by template (home, service page, blog post, landing page).
Fix templates, not individual pages. One template fix can move hundreds of URLs.
Use PageSpeed Insights on one representative URL per template to find the specific cause.
Ship the fix, then wait: field data is a rolling 28-day window, so improvements take several weeks to show.
Add a performance budget (bundle size, image weight, number of third-party tags) to your release checklist so the problem does not return.

Core Web Vitals Explained for the Marketers on Your Team

rokya elbarbary — Tue, 29 Sep 2026 12:48:34 +0000

This guide explains each metric in plain language, how to measure it, and where fixes usually come from.

The three metrics

Metric	Measures	"Good" threshold (Google)
LCP - Largest Contentful Paint	How long until the main content (usually a hero image or headline) is visible	2.5 seconds or less
INP - Interaction to Next Paint	How quickly the page responds visually after a tap, click or key press	200 milliseconds or less
CLS - Cumulative Layout Shift	How much content unexpectedly jumps around while loading	0.1 or less

Google assesses each metric at the 75th percentile of real page loads, separately for mobile and desktop. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024.

Field data vs lab data

Field data comes from real Chrome users (the Chrome User Experience Report, shown in Search Console and PageSpeed Insights). This is what counts.
Lab data comes from a simulated test (Lighthouse). It is repeatable and good for debugging, but it cannot measure INP directly and it does not reflect your real users' devices and networks.

A page can score well in Lighthouse and still fail in the field, usually on mid-range Android phones on mobile networks.

Where LCP problems usually come from

Slow server response (TTFB). Uncached HTML, slow APIs during server rendering, or no CDN close to your users.
The LCP image is discovered late. For example, a hero image set as a CSS background or injected by JavaScript. Put it in the HTML as an <img> and consider fetchpriority="high".
The LCP image is lazy-loaded. Never apply loading="lazy" to the above-the-fold hero.
Oversized images. Serve responsive sizes (srcset) and modern formats.
Render-blocking CSS and fonts. Inline critical CSS; use font-display: swap or optional.

Where INP problems usually come from

Long JavaScript tasks on the main thread - large bundles, heavy hydration, third-party scripts.
Tag manager bloat. Every chat widget, heatmap and pixel adds main-thread work. Audit tags quarterly and remove what nobody uses.
Expensive event handlers that do layout-heavy work synchronously. Yield to the main thread and defer non-urgent work.

Where CLS problems usually come from

Images and videos without width and height (or an aspect-ratio).
Late-loading banners, cookie bars or promos that push content down instead of overlaying it.
Web fonts that swap and change text size; match fallback font metrics.
Ads or embeds inserted without reserved space.

A workable process for marketing teams

Open the Core Web Vitals report in Search Console and group failing URLs by template (home, service page, blog post, landing page).
Fix templates, not individual pages. One template fix can move hundreds of URLs.
Use PageSpeed Insights on one representative URL per template to find the specific cause.
Ship the fix, then wait: field data is a rolling 28-day window, so improvements take several weeks to show.
Add a performance budget (bundle size, image weight, number of third-party tags) to your release checklist so the problem does not return.

UTM Governance: Keep Your Campaign Data Out of "Unassigned"

rokya elbarbary — Tue, 29 Sep 2026 12:45:35 +0000

UTM parameters are the cheapest attribution system you will ever own, and one of the easiest to break. One person tags a newsletter utm_medium=Email, another uses e-mail, a third forgets tags entirely - and a month later the channel report is fiction.

This note sets out a small set of rules that keeps campaign data clean in Google Analytics 4 and in any tool that reads the same parameters.

The parameters

Parameter	Required?	Describes	Example
`utm_source`	Yes	Who sent the traffic	`google`, `meta`, `linkedin`, `newsletter`
`utm_medium`	Yes	The type of channel	`cpc`, `paid_social`, `email`, `referral`
`utm_campaign`	Yes	The campaign or initiative	`2026q4_audit_offer`
`utm_content`	Optional	The specific creative or link	`carousel_v2`, `footer_link`
`utm_term`	Optional	Keyword (mainly paid search)	`marketing_subscription`
`utm_id`	Optional	A campaign ID that matches your ad platform or cost data	`cmp_1042`

GA4 also recognises utm_source_platform, utm_creative_format and utm_marketing_tactic if you need them.

Rule 1: lowercase everything

GA4 treats Email and email as different values. Agree that every UTM value is lowercase, with underscores instead of spaces.

Rule 2: `utm_medium` must match GA4's channel definitions

GA4's default channel grouping assigns sessions to channels such as Paid Search, Paid Social, Email and Organic Social largely by looking at the medium and the source. If your medium values do not match the patterns Google documents, sessions fall into Unassigned.

A safe, simple vocabulary:

Channel you intend	`utm_medium`	Notes
Paid search	`cpc`	Auto-tagging (gclid) handles Google Ads; use UTMs for other search engines
Paid social	`paid_social`	Pair with a recognised social `utm_source` such as `facebook`, `instagram`, `linkedin`
Organic social	`social`	For unpaid posts you publish yourself
Email	`email`	Newsletters and automated sequences
Display	`display`	Programmatic and banner placements
Affiliates / partners	`affiliate` or `referral`	Pick one and keep it

Check the current channel definitions in Google's documentation before finalising your list.

Rule 3: a campaign naming pattern

A pattern makes campaigns sortable and self-explanatory:

<yyyy><q|mm>_<objective>_<offer-or-theme>[_<market>]

Examples: 2026q4_leads_audit_offer_uae, 202611_awareness_brand_film.

Rule 4: never tag internal links

UTMs on links between pages of your own site start a new session attribution and overwrite the original source. Use them only on links that bring people into the site from somewhere else.

Rule 5: one builder, one log

Generate every tagged URL from a shared builder (a spreadsheet with data validation is enough).
Keep a log: date, owner, channel, final URL, and where it was used.
Validation dropdowns for utm_source and utm_medium remove most typos before they happen.

QA before launch

Open the tagged URL in a private window and confirm the landing page loads without redirects that strip query strings.
Check GA4 Realtime for the expected source / medium.
Confirm consent tools and redirects preserve parameters.
For paid platforms, check whether the platform's own tracking template or auto-tagging already adds parameters, so you do not double-tag.

Monthly clean-up

Review Traffic acquisition by session source / medium. Anything in "Unassigned" or with unexpected capitalisation points to a link that needs fixing at the source, not a report filter.

Structured Data Templates (JSON-LD) You Can Copy Into Your Templates

rokya elbarbary — Tue, 29 Sep 2026 12:43:09 +0000

Structured data tells search engines explicitly what a page is about: which organisation publishes it, who wrote an article, where a page sits in the site hierarchy. It does not guarantee a rich result, and Google has narrowed several rich result types over time, so treat markup as a way to describe your content accurately rather than as a ranking trick.

Google recommends JSON-LD, placed in a <script type="application/ld+json"> block. The templates below use only properties documented by Google or schema.org. Replace every value in angle brackets, and delete any property you cannot fill truthfully.

Organization (site-wide, usually on the homepage)

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "<Legal or trading name>",
  "url": "https://<your-domain>/",
  "logo": "https://<your-domain>/<path-to-logo>.png",
  "sameAs": [
    "https://www.linkedin.com/company/<handle>",
    "https://www.instagram.com/<handle>/"
  ]
}

Notes:

logo should be a crawlable image URL. Google documents its logo requirements in the Organization structured data guidelines.
Only list profiles in sameAs that you actually control.
Only add address or telephone if they are real and match what is shown on the page. Placeholder contact details in markup are worse than none.

Article (blog posts and guides)

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "<Title as shown on the page>",
  "datePublished": "<YYYY-MM-DD>",
  "dateModified": "<YYYY-MM-DD>",
  "author": [{
    "@type": "Person",
    "name": "<Author name>",
    "url": "https://<your-domain>/<author-page>"
  }],
  "image": ["https://<your-domain>/<hero-image>.jpg"]
}

Notes:

dateModified should change only when the content meaningfully changes.
If the author is the organisation rather than a person, use "@type": "Organization" for the author.

BreadcrumbList

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://<your-domain>/" },
    { "@type": "ListItem", "position": 2, "name": "Services", "item": "https://<your-domain>/services" },
    { "@type": "ListItem", "position": 3, "name": "<Current page>" }
  ]
}

The last item may omit item. The trail should match the breadcrumb that users see.

Service (describing what you offer on a service page)

Google does not currently show a dedicated rich result for Service, but the type is valid schema.org vocabulary and helps describe a page unambiguously.

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "<Service name>",
  "serviceType": "<e.g. Search engine optimisation>",
  "provider": { "@type": "Organization", "name": "<Your organisation>", "url": "https://<your-domain>/" },
  "areaServed": ["<Country or region>"],
  "url": "https://<your-domain>/<service-page>"
}

Types to handle with care

FAQPage: since 2023 Google shows FAQ rich results only for a limited set of well-known, authoritative government and health sites. Marking up a genuine FAQ is still valid, but do not expect a visual result.
HowTo: HowTo rich results have been deprecated in Google Search.
Review / AggregateRating: self-serving reviews of your own business are not eligible for review snippets. Never mark up testimonials you cannot substantiate.

Validation workflow

Validate syntax with the Schema Markup Validator.
Check eligibility with Google's Rich Results Test.
After deployment, watch the enhancement reports in Search Console for errors that appear at scale.
Keep markup in the template, generated from the same data as the visible page, so the two cannot drift apart.

A Technical SEO Crawl and Index Checklist for Developers

rokya elbarbary — Tue, 29 Sep 2026 12:35:08 +0000

Search visibility starts with three separate questions, and a page can fail any one of them independently:

Can a search engine discover and fetch the URL? (crawling)
Can it see the content once fetched? (rendering)
Does it choose to keep the page in its index, and under which URL? (indexing and canonicalisation)

Work through the checklist in that order. There is little point tuning titles on a page that is blocked in robots.txt.

1. Crawling

Check	How to verify	What good looks like
`robots.txt` is reachable	Request `/robots.txt` directly	Returns HTTP 200 (or 404 if you intentionally have none); never a 5xx, which can make Google pause crawling
Important paths are not disallowed	Read every `Disallow` rule; test key URLs in Search Console's robots.txt report	Templates, CSS and JS needed for rendering are crawlable
XML sitemap exists and is referenced	`Sitemap:` line in `robots.txt`; submitted in Search Console	Lists only canonical, indexable URLs that return 200
Internal links use real anchors	Inspect navigation and pagination	`<a href="...">` elements, not click handlers on `<div>` or `<span>`
No redirect chains on internal links	Crawl the site with a crawler of your choice	Internal links point straight at the final URL
Server responds consistently	Check server logs for Googlebot requests	Stable 200 responses; no bursts of 429 or 5xx

2. Rendering

Modern sites often build content in the browser. Google can render JavaScript, but rendering happens after the initial fetch and depends on every resource loading successfully.

Compare view-source with the rendered DOM (URL Inspection tool, "View crawled page"). Primary content, headings and internal links should exist in the rendered HTML.
Do not block the JavaScript or CSS files your templates depend on.
Avoid content that only appears after a user interaction (clicking a tab, scrolling an infinite list) if you need it indexed. Put it in the HTML or render it server-side.
Lazy-loaded images should use native loading="lazy" or a method that exposes the image URL in the rendered DOM.

3. Indexing and canonicalisation

Check	What to look for
`meta robots` and `X-Robots-Tag`	No accidental `noindex` left over from staging; check both the HTML and the HTTP headers
Canonical tags	One `rel="canonical"` per page, absolute URL, pointing at a 200, indexable URL
Duplicate variants	`http` vs `https`, `www` vs non-`www`, trailing slash, uppercase, tracking parameters - each should resolve to one canonical version via redirect or canonical
Status codes	Removed pages return 404 or 410; moved pages return 301 to the closest equivalent
Soft 404s	Thin "no results" or empty category pages returning 200 - either add content or return 404
Language versions	If you publish Arabic and English versions, use `hreflang` annotations that are reciprocal and point at canonical URLs

4. Page-level basics

A unique, descriptive <title> and meta description on every indexable template. Placeholder descriptions left over from a CMS theme are a common and easily fixed problem.
Exactly one visible H1 that describes the page. Duplicate or placeholder headings (for example a leftover "Heading" block) confuse users and are worth removing.
Descriptive internal anchor text rather than "click here".

5. After launch

Submit the sitemap and inspect a sample of key URLs in Search Console.
Watch the Pages (indexing) report for spikes in "Crawled - currently not indexed", "Duplicate without user-selected canonical" or "Blocked by robots.txt".
Re-run the crawl after every major release. Technical SEO regressions usually arrive with deployments, not with content.

A GA4 Event Naming Convention Your Whole Team Can Follow

rokya elbarbary — Tue, 29 Sep 2026 12:31:49 +0000

Google Analytics 4 lets anyone who can edit a tag create a new event name. That flexibility is useful for about six months, until the property contains Form_Submit, form_submit, formSubmit and lead_form_sent - all meaning the same thing and none of them comparable over time.

A written naming convention, agreed before tracking is implemented, prevents that. This note is a starting point you can adapt.

Rules that come from GA4 itself

These are platform constraints documented by Google, not preferences:

Event names are case sensitive. sign_up and Sign_Up are two different events.
Event names must start with a letter and use only letters, numbers and underscores.
Event names are limited to 40 characters; parameter names to 40 characters; parameter values to 100 characters in a standard property.
Some names and prefixes are reserved (for example names starting with google_, ga_ or firebase_, and automatically collected event names). Do not reuse them for custom events.
An event can carry up to 25 parameters. Parameters only become available in standard reports once registered as custom dimensions or metrics, and a standard property has a limited number of each - so register deliberately.

Check the current limits in Google's documentation before a large implementation; they occasionally change.

Our conventions

Rule	Example	Why
`snake_case`, all lowercase	`generate_lead`	Matches Google's recommended events; avoids case duplicates
Use Google's recommended event when one exists	`sign_up`, `login`, `generate_lead`, `purchase`, `view_item`	Unlocks built-in reports and keeps you compatible with future features
Custom events: `object_action`	`quote_request`, `calculator_complete`, `video_progress`	Readable in reports, sorts related events together
Put detail in parameters, not in the event name	`generate_lead` with `form_id=contact_footer`	Avoids hundreds of near-identical event names
No personal data in names or parameters	Never send email addresses, phone numbers or names	Google's policies prohibit sending PII to Analytics
Parameter values are stable identifiers	`form_id=pricing_modal` not `form_id=Pricing Modal (new!)`	Values survive design changes and translations

A minimal event dictionary

Keep a single table - in a spreadsheet or in your repository - that is the source of truth for every event. For example:

Event name	Trigger	Parameters	Key event?	Owner
`generate_lead`	Successful form submission (after server confirms)	`form_id`, `form_location`, `lead_type`	Yes	Marketing ops
`book_call_click`	Click on any "book a call" button	`button_location`, `page_type`	No	Marketing ops
`calculator_complete`	User reaches the result step of a calculator	`calculator_id`, `result_band`	No	Product
`file_download`	Enhanced measurement (automatic)	`file_name`, `file_extension`	No	-

A dictionary like this also makes QA possible: the tester checks the property against the table instead of against somebody's memory.

Implementation checklist

Write the event dictionary before touching Google Tag Manager or the codebase.
Fire lead events on confirmed success (a thank-you state or a server response), not on button click, or you will count failed submissions.
Use GTM's preview mode and GA4 DebugView to confirm names and parameter values.
Register only the parameters you will actually report on as custom dimensions.
Mark the few events that represent real business outcomes as key events; do not mark every click.
Review the dictionary each quarter and remove events nobody uses.

Common problems in audits

Duplicate events caused by a tag firing both from GTM and from hard-coded gtag.js.
Enhanced measurement form interactions double counting a custom lead event.
Parameters sent but never registered, so the data exists only in BigQuery exports.
Cross-domain journeys (for example a booking tool on another domain) breaking sessions and attributing leads to "referral".

DEV Community: rokya elbarbary

Test Your Redirect Map Before and After a Site Migration With a Small Python Script

What the script checks

The script

Running it

Where the redirect map comes from

Before and after launch

Limitations

A Content Brief Template for Writers, Editors and SEOs

Content brief

1. Purpose

2. Reader

3. Search intent

4. Outline

5. Evidence and sources

6. Internal links

7. Format and style

8. Call to action

9. Definition of done

Using the brief after publishing

Further reading

A Webhook Runbook for Marketing Automation That Never Loses a Lead

1. Map the flow before building it

2. Design the payload

3. Make every receiver idempotent

4. Handle failure deliberately

5. Secure the endpoints

6. Monitor what matters

7. Change management

8. Incident checklist

Further reading

A CRO Experiment Brief Template That Stops False Wins

Experiment brief

1. Observation

2. Hypothesis

3. Metrics

4. Design

5. Sample size and duration

6. Stopping rule

7. QA checklist before launch

8. Result and decision

Keeping a learning log

Further reading

A Bilingual Arabic/English (RTL + LTR) UX Checklist for Web Teams

Document and layout

Typography

Icons and imagery

Forms

Numbers, dates and currency

Content and navigation

Search and metadata

QA pass

Further reading

Core Web Vitals Explained for the Marketers on Your Team

The three metrics

Field data vs lab data

Where LCP problems usually come from

Where INP problems usually come from

Where CLS problems usually come from

A workable process for marketing teams

Further reading

Core Web Vitals Explained for the Marketers on Your Team

The three metrics

Field data vs lab data

Where LCP problems usually come from

Where INP problems usually come from

Where CLS problems usually come from

A workable process for marketing teams

Further reading

UTM Governance: Keep Your Campaign Data Out of "Unassigned"

The parameters

Rule 1: lowercase everything

Rule 2: utm_medium must match GA4's channel definitions

Rule 3: a campaign naming pattern

Rule 4: never tag internal links

Rule 5: one builder, one log

QA before launch

Monthly clean-up

Further reading

Structured Data Templates (JSON-LD) You Can Copy Into Your Templates

Rule 2: `utm_medium` must match GA4's channel definitions