DEV Community: BRANDLUMEO LLP

"Stale URLs After a Permalink Change: A Silent SEO Killer"

BRANDLUMEO LLP — Fri, 25 Sep 2026 10:39:37 +0000

While working on a multi-location WordPress site (separate landing pages for each city we serve), we changed a page's permalink structure to better match its focus keyword for SEO. The page itself looked fine after the change — but a few days later we noticed something easy to miss: the site's navigation menu and footer "Locations" links were still pointing to the old URL, which now returned a 404.

Here's what happened, and how we caught it.

How it happened

We updated the permalink for a location page (say, /kozhikode-old-slug → /kozhikode) to fix a Rank Math "focus keyword not found in URL" warning. The page content updated fine, and Rank Math's on-page SEO score improved immediately.

What we didn't immediately check: every other place on the site that linked to that page.

The main navigation menu still pointed to the old slug
The footer's "Locations" list still pointed to the old slug
Both were now serving visitors (and Googlebot) a 404 page

Why this is easy to miss

Permalink changes feel like a small, contained edit — you fix one page's URL, the page renders fine, and it's tempting to move on. But WordPress doesn't automatically update every internal link that points to the old URL. Menus, footers, related-post widgets, and even hardcoded links inside other pages' content can all still reference the stale slug.

For a multi-location site with several similar pages, this is especially easy to miss — the pages all look alike, and a stale link doesn't visibly break anything until someone actually clicks it (or Google crawls it).

How we caught it

Manually clicking through the main navigation and footer links after any permalink change
Checking Google Search Console's Pages report a few days later for new 404s / "Not found" entries
A quick site crawl (Screaming Frog or similar) to catch internal links pointing to old URLs across the whole site, not just the nav

The fix

Update every internal reference — nav menu, footer, related pages — to the new URL
Add a 301 redirect from the old URL to the new one anyway, as a safety net for any external links, bookmarks, or search results still pointing to the old slug
Re-crawl and verify — check that nothing else on the site still links to the old path

Takeaway

If you change a permalink for SEO reasons, treat it as a two-part job: updating the page itself, and auditing every internal link that points to it. A 301 redirect is good insurance, but it doesn't fix the visible broken links your own visitors and search engines will find first.

We're BrandLumeo, a digital marketing agency working across Kerala and Dubai — handling SEO, web development, and Meta Ads for growing brands. Curious how others catch these silent breakages on larger sites!

"We Almost Wasted Time on a 'High DA' Backlink List — Here's What We Do Instead"

BRANDLUMEO LLP — Sat, 12 Sep 2026 06:34:36 +0000

We recently got handed a few "high DA/PA backlink list" spreadsheets — the kind you can find all over SEO forums, with hundreds of sites ranked by Domain Authority and Page Authority. Before submitting our site to any of them, we decided to actually evaluate what we were looking at. Here's what we found, and how we're approaching backlinks instead.

The problem with DA/PA backlink lists

At first glance, a list of sites with DA 80-95 looks like a goldmine. But when we actually looked closer:

Many were generic web directories from the early 2010s (pre-Panda/Penguin era) — the kind Google's algorithm updates specifically targeted
Several were regional clones of the same platform (Craigslist variants for a dozen different cities, .com.ar directory networks that were clearly the same operator)
High DA sites like Amazon or eBay don't even accept "backlink submissions" in the first place — they were just noise in the list
Page Authority (PA) on most of these was surprisingly low (30-45), which usually signals a link farm rather than a genuinely authoritative page

None of this means DA/PA numbers are useless — it means a spreadsheet of them, stripped of context, tells you almost nothing about whether a link is worth having.

What we check before it counts as a "quality" link

Relevance — does the site's audience actually overlap with ours (marketing/dev/business), or is it a generic directory that accepts anything?
Real traffic — is this a site people actually browse, or just a database of submitted links?
Spam score — a quick Moz check for spam score and trust metrics catches a lot of the link-farm pattern early.
Follow vs nofollow — nofollow links (common on classifieds, forums, many directories) still carry referral traffic and brand value, but shouldn't be counted the same as genuine dofollow authority links.

What we're doing instead

Rather than chasing bulk directory submissions, we shifted to:

Publishing genuine technical content on platforms like Dev.to and Hashnode — real case studies from our own work (PageSpeed optimization, SEO fixes), not promotional posts
Business directories that actually vet listings — GoodFirms, Clutch — where the traffic is people actively looking for an agency, not a bulk-scraped link list
Cross-promoting on LinkedIn to get real eyes on the content, which matters more for referral traffic than the backlink itself
Tracking in Google Search Console, not just a rank tracker — actual impressions, clicks, and query data tell you far more than a DA number ever will

What we learned from Search Console along the way

A few things surprised us once we started actually watching the data instead of assuming:

Most of our early impressions were brand-name searches, not the topic keywords we expected
One blog post ended up indexed under two slightly different URLs (trailing slash mismatch) — a reminder that even small technical details affect how cleanly Google reads your site
Broad, competitive keywords ("best X in [city]") are unrealistic to expect quick movement on for a newer site — long-tail, specific content earns visibility faster

Takeaway

If someone hands you a "1000 high DA backlinks" list, open it before you use it. A handful of genuinely relevant links will do more for you than hundreds of unrelated directory submissions — and it won't put your site at risk of looking manipulative to Google.

We're BrandLumeo, a digital marketing agency working across Kerala and Dubai. Curious how others evaluate backlink opportunities before committing time to them!

"5 Sneaky Technical SEO Issues That Were Hurting Our Site's Indexing (and How We Fixed Them)"

BRANDLUMEO LLP — Fri, 04 Sep 2026 04:48:40 +0000

We recently went through a full technical SEO cleanup on our own agency site (Next.js, static export). A few of the issues we found were sneaky — they don't break the site visually, but they quietly hurt indexing and rankings. Here's what we fixed.

1. Sitemap trailing slash mismatch

Our sitemap listed URLs like /services/ (with trailing slash) but the actual pages resolved at /services (no slash). Google Search Console flagged some of these as "Page with redirect" or simply didn't index them properly.

Simplified fix in sitemap.js:

export default function sitemap() {
  return [
    {
      url: 'https://example.com/services', // no trailing slash — match your actual routes
      lastModified: new Date(),
    },
  ]
}

Lesson: your sitemap URLs must exactly match how your routes actually resolve — trailingSlash config in next.config.js needs to agree with what's in the sitemap.

2. Keyword stuffing cleanup

Some of our early pages had meta titles and descriptions that were overstuffed with keywords, trying to rank for too much at once. We rewrote them to be natural, specific, and under the recommended length (~60 chars for titles, ~155 for descriptions).

3. Canonical tags

We added canonical tags across all pages to avoid duplicate content issues, especially important on a static export where trailing slashes or query params can create near-duplicate URLs.

export const metadata = {
  alternates: {
    canonical: 'https://example.com/services',
  },
}

4. JSON-LD structured data

Added JSON-LD schema (Organization, LocalBusiness where relevant) to help Google understand what the business actually is — useful for rich snippets and local search relevance.

5. robots.js + sitemap.js setup

Instead of static robots.txt/sitemap.xml files, we used Next.js's built-in robots.js and sitemap.js route handlers — cleaner to maintain and less error-prone than hand-written XML.

Result

After these fixes, our previously stuck /services page got properly indexed in Google Search Console, and overall crawl errors dropped.

Takeaway

If pages aren't indexing the way you expect, check in this order:

Sitemap URLs vs actual route URLs (trailing slash mismatches are common)
Canonical tags pointing to the right version
Meta tags — over-optimization can hurt as much as under-optimization

We're BrandLumeo, a digital marketing agency working across Kerala and Dubai — handling everything from Meta Ads to web development and SEO. Happy to hear how others have handled similar indexing quirks!

How We Took a Next.js Site's PageSpeed Score from ~50 to 98

BRANDLUMEO LLP — Thu, 27 Aug 2026 05:56:01 +0000

While auditing one of our own agency's sites (built as a Next.js static export), we found the mobile PageSpeed score sitting around 50 — not great for a site meant to represent a digital marketing agency. Here's what we changed to get it to 98.

1. Converted images to WebP

Most of the images on the site were still JPG/PNG. Converting them to WebP alone cut file sizes significantly without any visible quality loss.

2. Migrated to `next/image`

Instead of plain <img> tags, we moved every image to Next.js's built-in Image component. This gave us automatic:

Lazy loading
Responsive sizing
Better format negotiation

Here's a simplified example of the approach:

import Image from 'next/image'

<Image
  src="/hero.webp"
  alt="Hero banner"
  width={1200}
  height={600}
  priority
/>

3. Optimized Google Fonts with `next/font`

We were loading Google Fonts the traditional way (via <link> tags), which adds render-blocking requests. Switching to next/font/google self-hosts the fonts and eliminates that extra network round-trip.

Simplified example:

import { Poppins } from 'next/font/google'

const poppins = Poppins({
  subsets: ['latin'],
  weight: ['400', '600'],
})

4. Cleaned up legal/meta pages

Missing pages and broken links were quietly hurting the crawl experience and, indirectly, the performance audit. Adding proper legal pages (privacy policy, terms) closed that gap.

Result

Mobile PageSpeed score: ~50 → 98

Takeaway

If your Next.js site is scoring low, check these three things first — they're usually the biggest wins for the least effort:

Image format + next/image usage
Font loading strategy
Missing/broken pages affecting crawl

We're BrandLumeo, a digital marketing agency working across Kerala and Dubai — handling everything from Meta Ads to web development. Would love to hear how others have tackled similar performance issues!

DEV Community: BRANDLUMEO LLP

"Stale URLs After a Permalink Change: A Silent SEO Killer"

"We Almost Wasted Time on a 'High DA' Backlink List — Here's What We Do Instead"

The problem with DA/PA backlink lists

What we check before it counts as a "quality" link

What we're doing instead

What we learned from Search Console along the way

Takeaway

"5 Sneaky Technical SEO Issues That Were Hurting Our Site's Indexing (and How We Fixed Them)"

1. Sitemap trailing slash mismatch

2. Keyword stuffing cleanup

3. Canonical tags

4. JSON-LD structured data

5. robots.js + sitemap.js setup

Result

Takeaway

How We Took a Next.js Site's PageSpeed Score from ~50 to 98

1. Converted images to WebP

2. Migrated to next/image

3. Optimized Google Fonts with next/font

4. Cleaned up legal/meta pages

Result

Takeaway

2. Migrated to `next/image`

3. Optimized Google Fonts with `next/font`