DEV Community: Gorilla Vibe

An Internal Link Audit with a Crawl Export and pandas

Gorilla Vibe — Mon, 19 Oct 2026 10:59:17 +0000

Internal links decide how authority and crawlers move through a site, and most teams only look at them when something is already broken. A crawl export plus a short pandas script is enough to answer three practical questions: which pages have almost no internal links, which links point at redirects or errors, and which anchor texts say nothing useful.

This walkthrough uses an "all inlinks" export from a desktop crawler (Screaming Frog calls it Bulk Export → Links → All Inlinks). The column names below match that export (Source, Destination, Anchor, Status Code); rename them if your tool differs. You also need a list of URLs that should be indexable, for example from your XML sitemap.

import pandas as pd

links = pd.read_csv("all_inlinks.csv")
links = links.rename(columns=str.strip)
links = links[links["Type"].fillna("Hyperlink").eq("Hyperlink")]   # ignore images, scripts, etc.

# 1) Unique internal links pointing at each destination (ignore repeats from the same source)
inlinks = (links.drop_duplicates(["Source", "Destination"])
                .groupby("Destination").size()
                .rename("unique_inlinks"))

# 2) Compare with the pages that should be discoverable
sitemap = pd.read_csv("sitemap_urls.csv", names=["Destination"])
audit = sitemap.merge(inlinks, on="Destination", how="left").fillna({"unique_inlinks": 0})

orphans = audit[audit["unique_inlinks"] == 0]
weak = audit[(audit["unique_inlinks"] > 0) & (audit["unique_inlinks"] <= 2)]
print("In sitemap but no internal links:", len(orphans))
print("In sitemap with 1-2 internal links:", len(weak))

Links that waste a hop or hit an error

bad = links[links["Status Code"].isin([301, 302, 307, 308, 404, 410, 500, 503])]
fix_first = (bad.groupby(["Destination", "Status Code"])
                .size().rename("links_pointing_here")
                .reset_index()
                .sort_values("links_pointing_here", ascending=False))
print(fix_first.head(25))

The destinations at the top of this list are the cheapest wins: updating one template or navigation block can remove hundreds of bad links at once. For redirects, change the internal link to the final URL rather than relying on the redirect.

Anchor text that carries no meaning

generic = {"click here", "read more", "learn more", "here", "more", "this page"}
anchors = links["Anchor"].fillna("").str.strip().str.lower()
share = anchors.isin(generic).mean()
print(f"Generic anchors: {share:.1%}")

top_generic_targets = (links[anchors.isin(generic)]
                       .groupby("Destination").size()
                       .sort_values(ascending=False).head(15))
print(top_generic_targets)

A high share of generic anchors is not an emergency, but for important pages a short descriptive anchor tells both readers and crawlers what the destination is about.

Reading the result

Orphans need either a real place in the navigation or a decision to retire them. Do not add links just to hit a number.
Pages with one or two links that matter commercially are candidates for contextual links from related content.
Re-run the script after each release and keep the numbers. A trend tells you more than a single snapshot.

Limits

A crawl only sees links present in the rendered HTML it fetched. Links added by JavaScript after load, or behind logins, may be missing unless the crawler renders JavaScript. Internal link counts are also not rankings; they are one input among many.

If you would like this kind of audit turned into a prioritised plan for your site, it is part of our SEO service.

References

Google Search Central: Link best practices for Google
pandas documentation: DataFrame.merge
Screaming Frog: SEO Spider user guide

Faceted Navigation and SEO: When to Index, Canonicalise or Block

Gorilla Vibe — Mon, 19 Oct 2026 10:58:53 +0000

Filters and sort options on a category page can multiply a few hundred products into millions of crawlable URLs. Most of those URLs are near-duplicates, and letting a crawler wander through all of them wastes requests and dilutes signals. The standard advice sounds simple ("block them", "canonicalise them"), but the three tools do different jobs, and using the wrong one gives a result you did not intend.

What each tool actually does

robots.txt disallow stops compliant crawlers from fetching a URL. It does not remove the URL from the index if other pages link to it, and Google cannot see a noindex or a canonical on a page it is not allowed to fetch.
rel="canonical" is a hint that a page is a duplicate of another URL. Google may follow it or may not, and the duplicate still has to be crawled for the hint to be read.
noindex (meta robots or X-Robots-Tag) keeps a crawlable page out of the index. The page still gets crawled, so it does not save crawl requests.

A decision table

Facet type	Example	Index?	Treatment
Has real search demand and a unique page purpose	`/shoes/running/`	Yes	Clean URL, unique title and copy, self-referencing canonical, in the sitemap
Combination with demand but fragile	`/shoes/running/red/`	Maybe	Only if the page has distinct content and stock; otherwise canonical to the parent
Sort order	`?sort=price_asc`	No	Canonical to the unsorted URL; keep out of internal links
Pagination	`?page=2`	Yes, as its own page	Self-referencing canonical; do not canonicalise page 2 to page 1
Stackable filters (3+ at once)	`?color=red&size=9&brand=x`	No	Disallow in `robots.txt` if crawling them is the problem; make the links non-crawlable
Internal search results	`/search?q=`	No	`noindex` and disallow, depending on how they are linked
Session or tracking parameters	`?sessionid=`, `?utm_`	No	Do not generate them in internal links; canonical to the clean URL

Order of operations

Decide which facets deserve to exist as pages. This is a product and SEO decision, not a technical one. A facet earns a URL only if people search for it and you can make the page useful.
Stop generating crawlable links to everything else. Filters implemented as buttons or form posts, not plain <a href> links with parameters, are the cleanest fix because the URLs are never discovered.
Add canonicals on the variants that will still exist as URLs.
Use robots.txt last, and only for patterns that are already not worth crawling. Do not disallow a URL you also want de-indexed through noindex, because the crawler will never see the tag.
Measure. Compare crawled URLs in your logs and the pages in the Search Console indexing report before and after.

A quick way to see how big the problem is: count the distinct parameter combinations in a crawl or log export. If that number is many times larger than your real catalogue, the site is producing crawl space you did not design.

Rebuilding filters and templates so the crawlable set matches the pages you actually want indexed is work our team handles under web platform development.

References

Google Search Central: Managing crawling of faceted navigation URLs
Google Search Central: Consolidate duplicate URLs
Google Search Central: Introduction to robots.txt

Checking Googlebot in Your Server Logs with grep and awk

Gorilla Vibe — Mon, 19 Oct 2026 10:58:22 +0000

Server logs are the only place where you can see what Googlebot actually requested, how often, and what it got back. Crawl reports from a tool show what a crawler can reach; logs show what Google did reach. You do not need a log-analysis product for a first pass. A few grep and awk commands on a standard access log answer the questions that matter: is Googlebot wasting requests on junk URLs, and is it hitting errors?

The commands below assume the common "combined" log format, where field 7 is the request path and field 9 is the status code. Check one line of your own log first, because CDNs and some servers reorder fields.

1. Only count real Googlebot traffic

The user-agent string can be faked by anyone, so a grep -i googlebot on its own over-counts. Google documents a two-step check: reverse DNS on the IP must resolve to a googlebot.com or google.com host, and the forward lookup of that hostname must return the same IP.

# take the IPs that claim to be Googlebot, then verify each unique one
grep -i 'googlebot' access.log | awk '{print $1}' | sort -u > claimed_ips.txt

while read ip; do
  host_name=$(host "$ip" | awk '/pointer/ {print $5}')
  case "$host_name" in
    *.googlebot.com.|*.google.com.)
      fwd=$(host "${host_name%.}" | awk '/has address/ {print $4}')
      [ "$fwd" = "$ip" ] && echo "$ip"
      ;;
  esac
done < claimed_ips.txt > verified_ips.txt

Then keep only the lines that start with a verified IP:

grep -F -f verified_ips.txt access.log > googlebot.log

2. What status codes is Googlebot seeing?

awk '{print $9}' googlebot.log | sort | uniq -c | sort -rn

A healthy site is mostly 200 with some 301 and 304. A visible share of 404, 410 or 5xx is the first thing to chase. A 5xx that appears only a fraction of the time is easy to miss in manual checks, so look at the proportion rather than whether it ever happened.

3. Where is the crawl budget going?

# the 20 most requested paths
awk '{print $7}' googlebot.log | sort | uniq -c | sort -rn | head -20

# how many requests carry a query string
awk '{print $7}' googlebot.log | grep -c '?'

# the same split by top-level folder
awk '{print $7}' googlebot.log | cut -d/ -f2 | sort | uniq -c | sort -rn | head

If parameter URLs (?sort=, ?color=, session or tracking parameters) make up a large share of requests while your important pages are crawled rarely, that is the signal to tighten internal links, canonicals and robots rules.

4. Which broken URLs are still being requested?

awk '$9 ~ /^(404|410|500|502|503)$/ {print $9, $7}' googlebot.log | sort | uniq -c | sort -rn | head -30

Paths that keep appearing here are usually either old URLs without a redirect or internal links that still point at a dead page. Fix the link, or add a permanent 301 to the closest live equivalent.

Limits

Logs only cover requests that reached your origin. If a CDN answers from cache, those hits will be missing unless you export the CDN logs.
A short sample misleads. Use at least a few weeks of data, and compare before and after a change rather than judging one day.
Logs tell you what was requested, not what was indexed. Pair them with Search Console's page indexing report.

If you want help turning crawl and log findings into a prioritised fix list, that is part of our SEO service.

References

Google Search Central: Verifying Googlebot and other Google crawlers
Google Search Central: Crawl budget management for large sites
Apache HTTP Server docs: Log files

Server-side lead events with the GA4 Measurement Protocol (and the pitfalls)

Gorilla Vibe — Sun, 18 Oct 2026 13:09:05 +0000

Browser tags miss leads. Ad blockers, consent banners, people closing the tab right after submitting, and thank-you pages that never load all mean that the generate_lead event in GA4 is often lower than the number of rows in your CRM. If you optimise paid campaigns on that number, you are optimising on a sample with a bias you cannot see.

A small, honest fix is to send the lead event from your server, at the moment the form submission is actually stored, using the GA4 Measurement Protocol. This post shows a minimal version and the pitfalls that make people give up on it.

What you need

A GA4 web data stream, its Measurement ID (G-XXXXXXX) and a Measurement Protocol API secret (Admin → Data streams → your stream → Measurement Protocol API secrets).
The visitor's GA client ID, captured in the browser and sent along with the form. Without it, GA4 cannot join the server event to the session that produced it.

Capture the client ID in a hidden field:

<input type="hidden" name="ga_client_id" id="ga_client_id">
<script>
  gtag('get', 'G-XXXXXXX', 'client_id', (id) => {
    document.getElementById('ga_client_id').value = id;
  });
</script>

Send the event when the lead is saved

Node.js 18+ (built-in fetch), called right after your form handler writes the lead to the database:

const MP_URL = 'https://www.google-analytics.com/mp/collect';

export async function sendLeadEvent({ clientId, leadId, formName, value = 0 }) {
  if (!clientId) return { skipped: 'no client id' }; // never invent one
  const url = `${MP_URL}?measurement_id=${process.env.GA4_MEASUREMENT_ID}` +
              `&api_secret=${process.env.GA4_API_SECRET}`;
  const body = {
    client_id: clientId,
    events: [{
      name: 'generate_lead',
      params: {
        form_name: formName,
        lead_id: leadId,          // lets you de-duplicate and reconcile with the CRM
        value, currency: 'AED',
        engagement_time_msec: 1,  // makes the event count toward active users
      },
    }],
  };
  const res = await fetch(url, { method: 'POST', body: JSON.stringify(body) });
  return { status: res.status };
}

Keep the API secret in an environment variable on the server, never in front-end code.

Validate before you trust it

The production endpoint returns 204 even for malformed payloads, so a "successful" request proves nothing. During development, post the same body to the debug endpoint, which returns a list of validation messages:

https://www.google-analytics.com/debug/mp/collect?measurement_id=...&api_secret=...

An empty validationMessages array is what you want. After that, confirm in GA4 DebugView, and then in the standard reports a day later.

Pitfalls

Double counting. If the browser tag also fires generate_lead, you will count most leads twice. Pick one source for the event. A clean split: the browser keeps form_start and form_submit, and only the server sends generate_lead.
Consent. Server-side does not mean consent-free. If a visitor declined analytics, do not send the event. Store the consent state with the lead and check it before calling sendLeadEvent.
Timestamps. If you queue events and send them later, set timestamp_micros. GA4 accepts events up to 72 hours in the past.
Spam. Send the event after your spam filter, not before. Otherwise the bot traffic you just blocked becomes "conversions".

The payoff

Once the event comes from the same place as the CRM row, the two numbers finally reconcile, apart from consent-declined leads, which you can count separately. That is the number worth importing into Google Ads or feeding to bidding. It is a small piece of the measurement work we do in performance marketing: fix what is counted before spending more on what is counted.

References

Google for Developers: Measurement Protocol (GA4)
Google for Developers: Validating events
Google Analytics Help: Recommended events: generate_lead

hreflang for English and Arabic sites: the five mistakes we see most

Gorilla Vibe — Sun, 18 Oct 2026 13:08:28 +0000

Bilingual English–Arabic sites are the norm across the GCC, and hreflang is where most of them quietly go wrong. The tags are simple, but the rules for how they must agree with each other are strict, and search engines ignore a whole cluster if one piece is broken. These are the five mistakes we find most often in audits, with the fix for each.

1. Missing return links

hreflang only works when both pages point at each other. If /en/pricing lists /ar/pricing as its Arabic alternate, then /ar/pricing must list /en/pricing back. One-way annotations are ignored.

<!-- on https://example.com/en/pricing AND on https://example.com/ar/pricing -->
<link rel="alternate" hreflang="en" href="https://example.com/en/pricing" />
<link rel="alternate" hreflang="ar" href="https://example.com/ar/pricing" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/pricing" />

The safest pattern is to output the same complete block on every page in the cluster, including a self-reference.

2. Invalid or over-specific codes

The value is a language code (ISO 639-1), optionally followed by a region code (ISO 3166-1 Alpha-2): ar, ar-AE, en-SA. We regularly see ar-UAE, en-UK and ae, which are all invalid. (UK is not the ISO code for the United Kingdom, and ae is a region, not a language.)

Only add a region when the content really differs by country, for example in prices, delivery or legal text. A single Arabic version for the whole GCC should just be ar.

3. Pointing at URLs that redirect, 404 or are noindex

Every URL in the cluster must return 200, be indexable and be its own canonical. Annotations that point at a redirect, a 404, a noindex page or a page whose canonical points somewhere else break the set. This happens most after a URL restructure, when the language switcher is updated but the hreflang generator still emits old paths.

A quick check: collect every href from your hreflang tags, request each one, and fail if any response is not a plain 200 without noindex.

4. Canonical tags that fight hreflang

A common CMS default canonicalises the Arabic page to the English one ("the English page is the original"). That tells search engines the Arabic page is a duplicate, and they never show it. Each language version needs a self-referencing canonical; hreflang then connects the versions.

5. Translating the slug but not the internal links

If the Arabic page lives at /ar/الأسعار but internal links and the sitemap still point at /ar/pricing (which redirects), crawlers keep landing on redirects. Either keep Latin slugs in both languages or make sure every internal link, sitemap entry and hreflang tag uses the final Arabic URL, percent-encoded consistently.

A sitemap alternative

For large sites, maintaining hreflang in the XML sitemap is easier to audit than in page heads:

<url>
  <loc>https://example.com/en/pricing</loc>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/pricing"/>
  <xhtml:link rel="alternate" hreflang="ar" href="https://example.com/ar/pricing"/>
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/pricing"/>
</url>

Use one method, not both. Two sources that disagree is mistake number one again.

Checklist

[ ] Every page outputs the full cluster, including itself
[ ] Codes are valid (ar, en, optional -AE/-SA), plus x-default
[ ] Every alternate URL returns 200, is indexable and is self-canonical
[ ] Language switcher, sitemap and hreflang use the same final URLs
[ ] Re-check after every URL migration

Getting this right is part of the technical groundwork we do for bilingual brands; see our SEO service for how we approach it.

References

Google Search Central: Tell Google about localized versions of your page
Google Search Central: Consolidate duplicate URLs
W3C: Language tags in HTML and XML

Catching flaky 404s before Google does: a 40-line URL stability check

Gorilla Vibe — Sun, 18 Oct 2026 13:07:34 +0000

A page that returns 200 when you open it in your browser can still be failing for search engines. We hit this on a Next.js site: the service pages loaded fine on every manual check, yet Bing reported them as 404 and Google slowly dropped them from the index. The cause was an intermittent failure in the data layer. Roughly three requests out of four came back as 404 with a noindex tag, and the fourth one, the one a human happened to see, was fine.

One request per URL will never catch that. You need to ask the same question many times and look at the distribution of answers.

The check: request every URL N times

The script below is plain Python 3 with no dependencies. It reads URLs from a file, requests each one N times with a short pause, and prints how often each status code appeared. It also flags a noindex in the response, because an error page that carries noindex is what actually gets a page dropped.

#!/usr/bin/env python3
"""url_stability.py - request each URL N times and report status-code distribution.
usage: python3 url_stability.py urls.txt [N]"""
import sys, time, collections, urllib.request, urllib.error

UA = "Mozilla/5.0 (stability-check)"

def fetch(url):
    req = urllib.request.Request(url, headers={"User-Agent": UA, "Cache-Control": "no-cache"})
    try:
        with urllib.request.urlopen(req, timeout=20) as r:
            body = r.read(200_000).decode("utf-8", "ignore").lower()
            return r.status, "noindex" in body
    except urllib.error.HTTPError as e:
        body = e.read(200_000).decode("utf-8", "ignore").lower()
        return e.code, "noindex" in body
    except Exception as e:
        return type(e).__name__, False

def main():
    urls = [u.strip() for u in open(sys.argv[1]) if u.strip() and not u.startswith("#")]
    n = int(sys.argv[2]) if len(sys.argv) > 2 else 20
    unstable = 0
    for url in urls:
        codes, noindex = collections.Counter(), 0
        for i in range(n):
            code, ni = fetch(f"{url}{'&' if '?' in url else '?'}_={time.time_ns()}")
            codes[code] += 1
            noindex += ni
            time.sleep(0.5)
        ok = codes.get(200, 0)
        flag = "OK " if ok == n else "BAD"
        unstable += ok != n
        print(f"{flag} {ok}/{n} ok  {dict(codes)}  noindex={noindex}  {url}")
    sys.exit(1 if unstable else 0)

if __name__ == "__main__":
    main()

A run against a healthy site prints one OK 20/20 line per URL. On the site we were debugging it printed lines like this:

BAD 5/20 ok  {404: 15, 200: 5}  noindex=15  https://example.com/service/seo

That single line explained weeks of confusing reports.

Details that matter

Bust caches on purpose. The _= query parameter forces a fresh response from CDNs and ISR caches. Run the check a second time without it to see what cached visitors and crawlers get. The two results can differ, and the difference tells you which layer is broken.
Twenty requests is a floor. Twenty requests per URL is enough to see a 25% failure rate reliably. For rarer failures, run it on a schedule and keep the output.
Exit codes make it CI-friendly. The script exits 1 if any URL is unstable, so you can run it after every deploy and fail the pipeline.
Check the bots too. Change the User-Agent to a crawler string to confirm that bots are not treated differently. If only one user agent fails, look at the middleware, the WAF and the bot rules first.

Typical causes once you find it

A CMS or API call fails and the page calls notFound(). In Next.js App Router code, if (!data) notFound() turns every upstream timeout into a real 404 with noindex. Fail loudly instead: return a 5xx (search engines retry those) or serve the last good copy.
Two app versions behind a load balancer. One instance knows the new routes and the other does not, so the response depends on which instance answers. Compare response headers, such as the build ID and server timing, between good and bad responses.
Edge caching an error. A single bad response cached for an hour looks like an outage. Make sure error responses are sent with Cache-Control: no-store.

After the fix

Re-run the check with N=50 and keep the log. Then resubmit the affected URLs in Search Console and Bing Webmaster Tools, and watch the coverage reports over the following week. For redesigns, add a permanent 301 from every old path to its new one. A missing redirect looks exactly like this problem from the crawler's side.

If you want a second pair of eyes on a platform or migration like this, our team covers it under web platform development.

References

Google Search Central: HTTP status codes and how they affect Google Search
Next.js docs: notFound
Bing Webmaster Guidelines: Bing Webmaster Tools help

Consultant, Agency or In-House? A Decision Checklist for Small Teams

Gorilla Vibe — Mon, 12 Oct 2026 12:05:18 +0000

Small teams hit the same fork sooner or later: do we hire someone, bring in a consultant for a few months, or sign with an agency? Each can be the right answer. They fail when the choice is made on price alone, so here is a checklist you can run in about twenty minutes.

First, name the real problem

Write one sentence that starts with "We need…". If it says "more leads" or "better branding", keep going until it describes something a person could actually do, such as "a landing page that converts mobile visitors from paid search" or "a tracking setup we trust".

When in-house is the right call

The work is continuous and needs deep knowledge of your product.
You can describe the role in a way that attracts senior people, and you can pay for them.
You have someone who can manage and review the output.

In-house is slow to start but compounds. It is a poor fit if the need is a three-month project.

When a consultant fits

You have a team but lack one specific skill: a measurement plan, a pricing review, a go-to-market sequence.
You want a decision, a plan or an audit, not months of execution.
The deliverable can be reviewed on a date.

Ask for a written scope, a named person and a handover document. A good consultant makes themselves less necessary.

When an agency fits

You need several skills at once (strategy, design, web, ads) and cannot hire all of them.
Work is ongoing but the volume goes up and down.
You want predictable monthly capacity rather than recruiting.

Ask who actually does the work, how many hours a month are included, and how reporting is done.

Five questions that settle most cases

Is this a project with an end date, or an ongoing function?
Do we already have someone who can brief and review the work?
How many different skills does it need?
How fast do we need to start?
What does it cost us if it goes wrong?

If most answers say "ongoing, with a reviewer and one skill", hire. If they say "a decision on a date", use a consultant. If they say "several skills, flexible volume, start soon", an agency is usually cheaper than building the same team.

A note on switching later

Whatever you choose, keep your accounts, tracking and files in your own name so you can change your mind. That single habit removes most of the risk from any of the three options.

If you are weighing a consultant for a specific decision, the consulting and advisory team at Gorilla Vibe works on exactly that kind of scoped, time-boxed engagement.

Design Tokens: Stop Your Brand Colours Drifting Between Figma and CSS

Gorilla Vibe — Wed, 30 Sep 2026 07:50:15 +0000

A brand guideline PDF says the primary colour is orange. Six months later the website has four slightly different oranges, the email templates have a fifth, and nobody can say which one is right.

Design tokens fix this by turning brand decisions into named, versioned data that both designers and developers consume. This post shows a small, practical setup you can adopt without a big design-system project.

What a design token is

A token is a name paired with a design decision:

{
  "color": {
    "brand": {
      "orange": { "$value": "#F26D25", "$type": "color" },
      "yellow": { "$value": "#FDBE37", "$type": "color" }
    }
  }
}

The $value / $type shape follows the format being standardised by the W3C Design Tokens Community Group. Tools such as Style Dictionary can read token files and generate CSS, iOS, Android or JavaScript outputs from the same source.

Use three tiers, not one

Putting raw hex values straight into components recreates the original problem. A three-tier structure keeps changes cheap:

Tier	Example name	Holds	Who changes it
Primitive	`color.brand.orange`	The raw brand palette	Brand owner, rarely
Semantic	`color.action.primary`	The role a colour plays	Design system owner
Component	`button.primary.background`	A specific component decision	Component owner

Semantic tokens point at primitives, and components point at semantic tokens. When the brand refreshes its orange, you change one primitive. When marketing wants a different call-to-action colour for a campaign, you change one semantic token, and no component code moves.

Output as CSS custom properties

The simplest delivery format for the web is CSS custom properties:

:root {
  /* primitives */
  --color-brand-orange: #F26D25;
  --color-brand-yellow: #FDBE37;
  --color-neutral-950: #141414;
  --color-neutral-50: #f5f5f5;

  /* semantic */
  --color-action-primary: var(--color-brand-orange);
  --color-surface: var(--color-neutral-50);
  --color-text: var(--color-neutral-950);
}

@media (prefers-color-scheme: dark) {
  :root {
    --color-surface: var(--color-neutral-950);
    --color-text: var(--color-neutral-50);
  }
}

.button-primary {
  background: var(--color-action-primary);
  color: var(--color-neutral-950);
}

Dark mode becomes a matter of remapping semantic tokens, not rewriting components.

Tokens are not only colours

Most brand drift comes from the things that are not colours:

Typography: font families, a type scale, line heights, and weights
Spacing: a small scale (for example 4, 8, 12, 16, 24, 32, 48) instead of arbitrary pixel values
Radius and elevation: corner radii and shadows
Motion: durations and easing curves

If your brand works in more than one script, for example Arabic and English, give each script its own typography tokens. Arabic type usually needs different sizes and line heights to read as comfortably as Latin text at the same visual weight.

Checks that keep tokens honest

Contrast checks in CI. Generate every text/background semantic pair and fail the build if any combination drops below the WCAG contrast ratio you have committed to.
Lint for raw values. A stylelint rule that rejects hex colours outside the token files stops drift at code review.
Version the token package. Treat token changes like an API: a changelog, semantic versioning, and a visual diff before release.
One source of truth. Designers and developers must edit the same token file (or a tool that syncs to it), never parallel copies.

Where to start this week

Export the brand palette and type scale into a single JSON token file.
Add semantic names for the five or six roles you actually use: primary action, surface, text, muted text, border, danger.
Generate CSS custom properties and replace hard-coded values in one high-traffic template.
Add the contrast check.

That is enough to stop the "five oranges" problem, and it scales into a full design system later.

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

Gorilla Vibe — 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

Gorilla Vibe — 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

Gorilla Vibe — 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

Gorilla Vibe — 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.

DEV Community: Gorilla Vibe

An Internal Link Audit with a Crawl Export and pandas

Links that waste a hop or hit an error

Anchor text that carries no meaning

Reading the result

Limits

Faceted Navigation and SEO: When to Index, Canonicalise or Block

What each tool actually does

A decision table

Order of operations

Checking Googlebot in Your Server Logs with grep and awk

1. Only count real Googlebot traffic

2. What status codes is Googlebot seeing?

3. Where is the crawl budget going?

4. Which broken URLs are still being requested?

Limits

Server-side lead events with the GA4 Measurement Protocol (and the pitfalls)

What you need

Send the event when the lead is saved

Validate before you trust it

Pitfalls

The payoff

hreflang for English and Arabic sites: the five mistakes we see most

1. Missing return links

2. Invalid or over-specific codes

3. Pointing at URLs that redirect, 404 or are noindex

4. Canonical tags that fight hreflang

5. Translating the slug but not the internal links

A sitemap alternative

Checklist

Catching flaky 404s before Google does: a 40-line URL stability check

The check: request every URL N times

Details that matter

Typical causes once you find it

After the fix

Consultant, Agency or In-House? A Decision Checklist for Small Teams

First, name the real problem

When in-house is the right call

When a consultant fits

When an agency fits

Five questions that settle most cases

A note on switching later

Design Tokens: Stop Your Brand Colours Drifting Between Figma and CSS

What a design token is

Use three tiers, not one

Output as CSS custom properties

Tokens are not only colours

Checks that keep tokens honest

Where to start this week

Further reading

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