DEV Community: Nooralto1

Forms that lose leads silently

Nooralto1 — Fri, 25 Sep 2026 02:22:14 +0000

Forms that lose leads silently

A contact form can look perfect and still throw away every lead that comes through it. The visitor
fills the fields, clicks submit, sees a thank you message, and leaves satisfied. Nobody on either
side knows the message never arrived. This is a different failure than the one everyone talks about,
the confusing layout or the field that asks for too much. Here the form works, in the sense that it
renders, accepts input, and reports success. It just doesn't deliver.

The thank you page lied

Most contact forms do two separate things: they confirm the submission on the client, and they try
to send an email on the server. Those two steps are not the same operation, and a lot of
implementations treat them as if they were. The browser gets a 200 response and shows the success
state the moment the server accepts the request, not once the mail has actually gone out. If the
mail step then fails, because an API key expired, a transactional email provider changed its
authentication requirements, or a PHP mail() call silently returns false on a server that never
had a real MTA configured, nothing tells the visitor. Nothing tells the business either, unless
someone is watching server logs that nobody watches. The form has told everyone it worked. It hasn't.

This is worth testing directly rather than trusting the interface: submit the form, then go and
check the inbox it's supposed to reach, not the confirmation screen.

Delivered doesn't mean read

Assume the send actually happens. The message can still land somewhere nobody checks. A domain
that sends form notifications without SPF and DKIM records configured gets treated by receiving
mail providers as an unverified sender, and unverified senders get filtered, quietly, without a
bounce. There is no error anywhere in this chain. The form succeeded, the email sent, and it sat in
a spam folder that gets emptied once a month. A business can run for a long stretch believing its
site simply isn't generating inquiries, when in fact it's generating them and losing them at the
mail server. Checking these records takes minutes with any DNS lookup tool. Almost nobody does it
until they've already lost the leads.

The button that looks broken but isn't

Client-side validation is supposed to help, catching a malformed email or a missing required field
before the request goes out. It only helps when it's visible. A validation rule that blocks
submission but fails to render any message, because a CSS class didn't load, because a JavaScript
error upstream stopped the error-rendering function from running, or because the error text was
styled the same color as the background, leaves the visitor clicking a button that appears to do
nothing. Most people try twice. Then they assume the site is broken and leave, often without
emailing or calling instead, because a form that seems broken doesn't inspire confidence in the
rest of the site. This failure mode is worse than the mail delivery problem in one respect: it
happens in front of the visitor, and it still generates zero signal on the business side.

When the plugin stops working and nobody notices

Sites built on a CMS often hand form handling to a third-party plugin or an embedded widget from
an external service. These integrations update on their own schedule, sometimes automatically, and
an update can change an API contract, deprecate an endpoint, or quietly disable a feature on a
free tier. The widget keeps rendering. The fields keep accepting text. The submit button keeps
being clickable. What stops is the delivery, somewhere behind the interface, with no error surfaced
in the browser and often none in the plugin's own dashboard. Weeks can pass before someone thinks
to test it, usually after noticing that inquiry volume has dropped for no obvious reason. A site
built without dependence on a black-box widget doesn't remove every risk, but it removes this
category of it, and it's one of the reasons a
custom-built contact flow is worth the extra
setup over a bundled plugin nobody on the team can inspect.

A working form and a form that delivers are not the same thing

That's really the point underneath all four failure modes. The interface tells you the form
rendered. It tells you the button was clickable. None of that tells you whether a message reached
an inbox someone actually reads. The only way to know is to submit the form the way a real visitor
would, on a schedule, and check the destination, not the confirmation screen. Set a calendar
reminder, or better, automate a monthly test submission with an alert if the expected email doesn't
land within a few minutes. It costs almost nothing to check. It costs real inquiries not to.

None of this shows up in a design review. A form can pass every visual and usability check and
still fail at the one job it has. The fix isn't more polish on the front end, it's verifying the
plumbing behind it, on a schedule, the same way anyone would monitor an API endpoint that mattered.

Written by the team at Nooralto, a web and SEO studio working between Agadir and Paris.

Observability for a small business website

Nooralto1 — Fri, 25 Sep 2026 02:16:32 +0000

Observability for a small business website

A redesign ships, the team moves on to the next project, and the site enters a phase nobody plans
for: the months where nothing about it is actively worked on, but plenty can still quietly break.
Large engineering teams call the discipline that watches for this observability, and treat it as a
first-class part of running a service. A small business site rarely gets the same treatment, not
because the need is different, but because nobody thought to set it up before launch, when it was
cheapest to add.

Uptime is the easy part, and the least useful on its own

A basic uptime check, pinging the homepage every few minutes and alerting if it stops responding,
catches the most dramatic failure and almost nothing else. A site can return 200 OK on its
homepage while the booking form on a different page silently stopped submitting three weeks ago,
because a script update broke the endpoint it posts to. Uptime monitoring answers "is the site
technically online," which is a real but narrow question next to "can a visitor actually do the
thing this site exists for."

Synthetic checks that test the thing that matters

A synthetic check that actually submits a form, on a schedule, against a test address, and confirms
a confirmation email or a webhook fires within a reasonable window, catches the failure uptime
monitoring misses entirely.

// A minimal synthetic check, run every 15 minutes
async function checkContactForm() {
  const res = await fetch('https://example.com/api/contact', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      name: 'Synthetic Check',
      email: 'synthetic-check@example.com',
      message: 'automated check, ignore',
    }),
  });
  if (res.status !== 200) {
    throw new Error(`contact form returned ${res.status}`);
  }
}

Running this against the real endpoint, not a staging copy, is what makes it trustworthy: a check
against staging proves staging works, which was never the question.

Certificate and domain expiry, on a calendar nobody remembers

A TLS certificate or a domain registration expiring is entirely predictable and entirely
preventable, and it is also one of the most common causes of a site going dark with no code change
behind it at all. Auto-renewal handles most of these silently until the one year it does not,
because a payment method expired or a renewal setting changed. A monitor that checks the expiry
date on both, on a weekly schedule, and alerts thirty days out rather than the day of, turns a
guaranteed future incident into a calendar reminder.

Real user metrics, not just lab scores

A performance audit run once, in a lab environment, on a fast connection, describes a version of
the site nobody's actual visitor experiences. Real user monitoring, collecting Core Web Vitals from
actual visits, catches what a lab test cannot: a specific mobile carrier with slow DNS in one
region, a third-party script that only loads slowly for visitors outside the country the site was
tested from, a page that degrades specifically for the segment of traffic converting best. The gap
between a lab score and what real visitors experience is often where a redesign's promised
improvement quietly evaporates in the weeks after launch.

What actually deserves an alert

Monitoring everything sounds safer than monitoring a few things, and it produces the opposite
result: an alert channel nobody reads because most of it is noise, and the one alert that mattered
gets lost in it. A short list, watched consistently, beats a long list ignored after the second
week: the site responds, the primary conversion action (a form, a booking, a checkout) completes
end to end, the certificate has more than thirty days left, and Core Web Vitals for real visitors
have not regressed past a set threshold.

Building this in before launch, not after an incident

Observability set up after the first bad month is observability that arrives too late to prevent it,
only to explain it after the fact. The redesign work at Nooralto
treats this monitoring layer as part of the launch checklist rather than a separate project to
revisit someday, because the cost of wiring a synthetic check and a certificate monitor at launch
is a fraction of what a week of silent downtime costs a business that only finds out when a client
mentions the site looked broken.

A site that nobody is actively watching is not stable. It is untested since the day it shipped, and
the first person to notice a failure is usually a visitor who does not bother reporting it, just
leaves.

Nooralto builds websites and runs search optimisation for businesses, from Agadir and Paris.

Migrating from PrestaShop to Shopify without losing search rankings

Nooralto1 — Fri, 25 Sep 2026 02:10:50 +0000

Migrating from PrestaShop to Shopify without losing search rankings

A PrestaShop-to-Shopify migration gets pitched, correctly, as an upgrade: less server maintenance,
a checkout that does not need a security patch every quarter, a theme ecosystem that does not
require a developer for every small change. What the pitch usually skips is that the two platforms
structure URLs, categories and product data differently enough that a lift-and-shift migration,
done without mapping the difference deliberately, drops search rankings for weeks or permanently.

The URL structure does not translate on its own

PrestaShop, out of the box or with a common SEO module enabled, tends to produce URLs like
/17-category-name/42-product-name.html, with numeric identifiers baked in and an .html
extension. Shopify generates /collections/category-handle and /products/product-handle, no
extension, no numeric prefix. There is no automatic way to preserve the old pattern; the platform
dictates the shape.

That means every single indexed PrestaShop URL needs an explicit redirect to its Shopify
equivalent, not a pattern-based rewrite rule. A generic rule stripping .html and renumbering
would work for some URLs and silently mismatch others, particularly where French accented
characters in a product name got encoded differently by each platform's slug generator.

Categories and collections are not the same structure

PrestaShop categories can nest arbitrarily deep, and a product can live in exactly one category by
default. Shopify collections are flatter, and a product can belong to several collections
simultaneously through tags or manual assignment, with no native parent-child nesting shown in the
URL. A PrestaShop store with Home > Kitchen > Cookware > Cast Iron as a category path has no
direct Shopify equivalent; the migration has to decide whether that becomes one collection, a
collection with a tag filter, or gets flattened into Cookware with Cast Iron demoted to a
product tag. This decision changes which URL should receive the redirect, so it has to happen
before the redirect map gets built, not after.

Exporting the map, and importing it Shopify's way

Old PrestaShop URL,New Shopify URL
/17-cookware/42-cast-iron-pan.html,/products/cast-iron-pan
/12-kitchen.html,/collections/kitchen

Shopify's admin accepts bulk redirects as a CSV import under URL Redirects, which is the
mechanism to use rather than reproducing an Apache or nginx rewrite layer that Shopify does not
give direct access to. The two-column format above is the whole contract; the discipline is making
sure every row maps to a URL that actually resolves, not to a category that got merged or a product
that got discontinued along the way, in which case that row should point to the closest surviving
collection instead of guessing at a homepage fallback.

Structured data written by a different hand

PrestaShop's product schema, whether from the core or a module, and Shopify's theme-generated
Product schema rarely produce identical output. Price formatting, currency codes, and whether
availability reflects real-time stock or a static value at theme install time can all differ. A
rich result that showed price and stock before the migration can vanish for a week simply because
the new theme's schema block uses a different field name or omits priceCurrency entirely,
something worth checking directly on a handful of product pages before calling the migration done,
rather than assuming the theme handled it correctly by default.

Language and multistore setups need their own mapping

PrestaShop's multistore and multilingual features often produce URL patterns with a language or
store prefix that Shopify's own multi-market or multi-language setup structures differently.
Treating this as a detail to sort out after launch is how a bilingual store loses its French
rankings while someone is still debugging why the English ones redirect correctly.

A store selling into both France and Morocco through separate PrestaShop language trees needs each
tree mapped to its own Shopify market or language variant before launch, with its own redirect rows.
Merging them into a single default market to save setup time is how one language ends up redirecting
correctly while the other quietly loses its indexed pages for weeks, because nobody checked the
smaller of the two traffic sources until the monthly report flagged the drop.

What actually gets checked after cutover

Watching organic traffic in the days after launch answers little on its own, because traffic always
dips during a platform change. What matters is the index coverage report: are old URLs showing as
properly redirected, or as errors. The approach this kind of migration follows at Nooralto treats the
redirect map, not the new theme, as the actual deliverable of the project, because a beautiful new
storefront sitting behind broken redirects is invisible to the search traffic it was supposed to
keep.

A platform migration is rarely undone by the new platform being worse. It is undone by treating the
gap between two URL structures as an afterthought instead of the center of the project.

Nooralto builds websites and runs search optimisation for businesses, from Agadir and Paris.

Structured data for a small hotel site: which schema actually earns its place

Nooralto1 — Fri, 25 Sep 2026 02:05:08 +0000

Structured data for a small hotel site: which schema actually earns its place

A hotel site accumulates structured data the way it accumulates plugins: one gets added because a
theme ships it, another because a booking widget injects its own block, a third because someone
once read that schema helps rankings and pasted a generic template without adapting it. The result
is rarely wrong in a way that throws an error. It is wrong in a way that describes a hotel that does
not quite match the one a guest is looking at.

Hotel, not just LocalBusiness

LocalBusiness validates and renders without complaint on a hotel page, which is exactly the
problem: it is the wrong type, and nothing forces anyone to notice. Hotel is a more specific type
under the same schema.org tree, and it carries fields a generic business listing does not:
checkinTime, checkoutTime, amenityFeature, starRating when the property actually holds a
rating from a real authority, petsAllowed. A validator that only checks for valid JSON will pass
either type. Only a human deciding which type actually describes a hotel with rooms, check-in
hours and amenities will catch the mismatch.

{
  "@context": "https://schema.org",
  "@type": "Hotel",
  "name": "Example Riad",
  "checkinTime": "14:00",
  "checkoutTime": "12:00",
  "amenityFeature": [
    { "@type": "LocationFeatureSpecification", "name": "Wifi", "value": true },
    { "@type": "LocationFeatureSpecification", "name": "Pool", "value": true }
  ],
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Marrakech",
    "addressCountry": "MA"
  }
}

Rooms are a separate entity, not a paragraph

A room described only in prose inside the hotel's description field gives a crawler nothing to
extract. Room (or HotelRoom, depending on how detailed the site needs to be) is its own type,
nested or linked under the hotel, and it is where occupancy, bed configuration and price range
belong. A site with six room types deserves six room entities, not one paragraph that lists them
comma-separated. The nesting also matters for maintenance: a room that gets renamed or retired
should not require editing a block of hand-written prose buried in a JSON string.

Price ranges, not fabricated numbers

priceRange is tempting to fill in with a plausible-looking string and forget. The trouble is that
guests, and increasingly AI answer engines summarising a page, treat that field as current. A
priceRange left over from a rate that changed two seasons ago is worse than no priceRange at
all, because it sets an expectation the booking engine will contradict at checkout. If pricing
changes with season or availability and nobody owns updating this field, it is more honest to leave
it out than to ship a number the site itself does not stand behind.

The widget conflict nobody checks for

A booking engine embedded as a third-party widget frequently injects its own Hotel or Product
schema into the page, separate from whatever the site's own template emits. Two blocks describing
the same property, with different check-in times or a different address format, do not cancel each
other out; a parser reads both and has no way to know which one to trust. This is worth an actual
check, not an assumption: view the rendered page source after the widget loads, search for every
application/ld+json block on the page, and confirm there is exactly one describing the hotel
itself. If there are two, one of them needs to be suppressed, usually by a configuration flag in the
booking widget rather than by fighting the template.

Where this actually pays off

None of this changes how the site looks to a visitor. It changes what shows up as a rich result in
search, and increasingly what an AI system quotes when a traveler asks it to compare a few
properties instead of scrolling a search results page. On a direct-booking hotel site built with this in mind, the schema is generated
from the same room and rate data the booking engine already reads, rather than typed once by hand
and left to drift the next time a room is renamed or a rate structure changes.

Testing it like any other output

The same discipline that applies to any structured data applies here: validate the shape before it
ships, not after a rich result silently disappears. A short script that fetches the rendered hotel
page, extracts every ld+json block, and asserts there is exactly one Hotel entity with a
checkinTime, an address and at least one amenityFeature, catches a broken block on the next
deploy instead of three months later, when someone finally notices the star rating vanished from
search results and has no idea why.

A small hotel site does not need every schema type schema.org offers. It needs the handful that
actually describe what a guest is trying to confirm before booking: is there a room available for
these dates, what time can they check in, and is the property what the photos suggest it is.
Everything else is noise a crawler has to parse through to find the part that matters.

Nooralto builds websites and runs search optimisation for businesses, from Agadir and Paris.

When a CMS becomes the bottleneck

Nooralto1 — Fri, 25 Sep 2026 01:59:26 +0000

When a CMS becomes the bottleneck

Every CMS earns its place at some point. Someone picked it because it matched what the business
published back then: a handful of pages, a blog, maybe a product catalog with a dozen fields. The
choice was reasonable. The problem shows up years later, after the business has changed shape
several times and the CMS has been patched to follow, never redesigned to lead.

The signs are rarely dramatic. Nobody calls a meeting to announce that the content model has
failed. Instead, a marketing coordinator mentions, almost in passing, that she updates the team
page and the "who we are" section separately, because the CMS has no way to say that a person on
the team page is the same person quoted in a case study. Two records, two places to remember, two
chances to drift out of sync. That is not a training problem. That is a schema that was never built
to relate one type of content to another.

The friction that actually triggers a rebuild

"The CMS is old" rarely moves a budget. What moves it is someone tracing a delay back to its
source and finding the platform underneath it. A few patterns repeat across almost every migration
project:

A content type stops matching what the business sells. A services company that used to publish
one kind of page now runs three different sales motions, each needing its own fields, its own
relationships to case studies and pricing, its own approval flow. The CMS still has one generic
"page" type with a rich text field, so editors invent conventions: a bolded line means this, a
specific heading level means that. None of it is enforced. None of it is queryable. It works until
the person who invented the convention leaves.

A plugin graph turns into a liability. Each plugin solved a real problem when it was installed: a
form builder, a gallery, an SEO panel, a caching layer that only plays well with specific versions
of the others. Updating any one of them means checking whether it breaks the three that depend on
its old behavior. At some point nobody updates anything, and the site runs on a stack that stopped
receiving security patches two major versions ago, because the risk of updating now outweighs the
risk of standing still.

A simple content change needs a developer. This is the clearest tell. A client asks to change a
phone number in a footer, or reorder three items in a list, and the answer is "let me check with
the dev." Over years of patches, template logic and content ended up tangled in the same file:
conditional blocks that only make sense if you know the history of the site, hardcoded values
sitting next to fields that were supposed to replace them. The people who could safely touch that
code moved on, and everyone left is afraid to.

Page builders start working against the page. Drag-and-drop editors that felt liberating at launch
accumulate nested rows, columns and widgets that never get cleaned up, because removing a block
someone might still need feels riskier than leaving it. Every new page starts from a slightly
heavier baseline than the last. Load times creep up. The editor who just wants to publish a press
release has to wade through a builder interface that was designed for landing pages, not for a
three-paragraph announcement.

What a migration actually fixes

None of this gets solved by a theme change or a plugin cleanup. It gets solved by deciding, on
paper, what the business actually publishes now, not what it published when the CMS was chosen,
and building a content model around that reality: explicit relationships between content types
where the business needs them, fields that map to how editors already think about the content,
and templates that pull from that structure instead of encoding logic that only one developer
understands. Teams rebuilding around that principle often start with the same conversation used to
scope a full custom website build, because
the content model has to be settled before a single template gets written, not patched in after
launch.

The tell that a migration is overdue is not a design that looks dated. It is a team that has
learned to work around its own publishing tool: duplicate records, invented formatting
conventions, a backlog of "quick changes" that all need a developer, pages that get heavier every
quarter without anyone deciding they should. Those are architectural symptoms, not cosmetic ones,
and no amount of editorial discipline fixes a content model that was never built for what the
business does today.

Migrating is disruptive enough that most teams put it off until the workaround culture is fully
entrenched. By then the real cost is not the migration itself. It is every month spent maintaining
two versions of the truth because the old system never learned to relate them.

The team at Nooralto has walked several clients through exactly this kind of rebuild, from Agadir and from Paris.

What a slow first byte costs you

Nooralto1 — Fri, 25 Sep 2026 01:59:05 +0000

What a slow first byte costs you

Open the network tab on a page that "feels slow" and the first thing worth looking at is rarely the
JavaScript bundle or the image sizes. It's the gap between the request going out and the first byte
of the response coming back. On a healthy server that gap is a few dozen milliseconds. On a lot of
sites it sits well past a full second, and everything downstream, rendering, hydration, paint,
inherits that delay before a single pixel has been drawn. Time to first byte gets treated as a
footnote in most performance audits. It shouldn't be. It's the one number that a crawler pays for
directly, out of a budget that isn't unlimited.

Crawl budget is a time budget, not a page count

Googlebot allocates a finite amount of time to a site per crawl session, not a finite number of
URLs. That distinction matters more than most technical SEO checklists let on. A site with fast
responses gets more pages crawled per session simply because each fetch finishes quickly and the
crawler moves to the next URL. A site with a slow origin burns the same time budget on fewer pages,
because every request sits there waiting on TTFB before the crawler has read a single tag of HTML.

This shows up clearly in server logs once you cross-reference Googlebot's user agent against
response times. Pages behind slow endpoints get crawled less often, and new pages behind a slow
section of the site take longer to get picked up at all, not because they're unimportant, but
because the crawler ran out of time budget before it reached them. A publishing site adding
category or tag pages behind a database-driven archive view will often see exactly this pattern:
the new URLs exist, they're linked internally, and they still take weeks to show up in the index,
because every fetch into that section of the site costs the crawler more time than a fetch anywhere
else.

TTFB is upstream of Largest Contentful Paint

Largest Contentful Paint measures when the biggest visible element finishes rendering, and it feeds
directly into Core Web Vitals, which sits inside the ranking systems Google has described as using
page experience signals. TTFB is not LCP, but it's the floor LCP is built on: nothing the browser
does to render content can start until the first byte of the document arrives. A page with a
lightweight hero image and clean CSS can still post a bad LCP score if the server takes 1.8 seconds
to respond, because that 1.8 seconds happens before the browser has anything to paint at all. Teams
that spend weeks compressing images and deferring scripts while ignoring a slow origin are
optimizing the smaller half of the number.

Where the time actually goes

Profiling a slow origin usually turns up one of three patterns, and none of them involve caching.

An unindexed query is the most common. A page that joins a few tables to build a listing runs fine
in development against a few hundred rows and turns into a multi-second query in production against
a few hundred thousand. EXPLAIN on the query usually shows a full table scan where an index would
have turned it into a lookup. Nobody notices until the table grows.

A synchronous third-party call is the second. A page fetching stock levels, shipping rates, or a
loyalty balance from an external API on every request is only as fast as that API's slowest
response, and that response happens inline, before the server can send anything back. When the
third party has a bad day, so does every page that calls it.

The third is a CMS or framework doing work on every request that belongs at build time. Rendering a
page from a template and a set of content blocks on each hit, recomputing the same navigation tree
or the same related-posts query for every visitor, is expensive in a way that never shows up in a
local dev environment where traffic is one person clicking around. Under real load, that per-request
computation is what an SEO audit built around server response time
tends to surface first, well before it gets anywhere near meta tags or heading structure.

What this looks like from a waterfall

A slow TTFB rarely arrives with a label attached. It shows up as a long blank bar at the start of a
waterfall, before any of the labeled phases begin. The instinct is to look at what comes after that
bar, because that's where the named metrics live. The more useful instinct is to ask what the server
was doing during it: which query ran, which API got called, which computation happened that
shouldn't have needed to happen at all. That's a database and application question before it's a
frontend one, and treating it as one is usually what gets the number down.

Written by the team at Nooralto, a web and SEO studio based in Agadir and Paris.

A build step that refuses to ship broken links

Nooralto1 — Fri, 25 Sep 2026 00:12:19 +0000

A build step that refuses to ship broken links

Most teams check for broken links the way they check smoke detector batteries: once a quarter, with a tool that crawls the live site and spits out a spreadsheet nobody reads before the next release. By the time the audit runs, the broken link has been live for weeks and possibly already flagged by a user who did not bother reporting it.

The fix is to move the check earlier and make it a gate instead of a report. Crawl the generated output before it deploys, fail the build on errors that are the site's fault, and warn on the ones that are not.

Crawl the build output, not the live site

Checking the deployed site catches problems after they ship. Checking the static output the build just produced catches them before, and it is faster too: no network latency, no CDN cache to fight, just files on disk.

// scripts/crawl-links.mjs
import { readFileSync, readdirSync, statSync, existsSync } from 'node:fs';
import path from 'node:path';

function collectHtmlFiles(dir, files = []) {
  for (const entry of readdirSync(dir)) {
    const full = path.join(dir, entry);
    if (statSync(full).isDirectory()) {
      collectHtmlFiles(full, files);
    } else if (entry.endsWith('.html')) {
      files.push(full);
    }
  }
  return files;
}

function extractLinksAndIds(html) {
  const links = [...html.matchAll(/href="([^"]+)"/g)].map((m) => m[1]);
  const ids = new Set([...html.matchAll(/\sid="([^"]+)"/g)].map((m) => m[1]));
  return { links, ids };
}

A regex is enough here. The build output is markup this same pipeline generated, not arbitrary HTML from the web, so the shape of href and id attributes is known and consistent.

Internal links are the site's fault, external links are not

The distinction that matters is who can fix the problem. An internal link pointing at a page that does not exist in the build is a bug in the site: someone renamed a route, deleted a page, or typo'd a path. That should fail the build. An external link returning a 404 might be a bug on someone else's server, or a site that restructured its URLs months ago without telling anyone. Worth knowing, but not a reason to block a deploy that has nothing to do with it.

function classifyLink(href, currentFile, distRoot) {
  if (href.startsWith('#')) return { kind: 'anchor', target: currentFile, fragment: href.slice(1) };
  if (/^https?:\/\//.test(href)) return { kind: 'external', url: href };
  if (href.startsWith('mailto:') || href.startsWith('tel:')) return { kind: 'skip' };

  const [pathPart, fragment] = href.split('#');
  const resolved = path.join(path.dirname(currentFile), pathPart || '');
  const candidate = resolved.endsWith('.html') ? resolved : path.join(resolved, 'index.html');
  return { kind: 'internal', target: candidate, fragment };
}

Anchors get checked against the target page's own id set, whether that page is the current one or a different internal page. A link to /pricing#faq is only correct if /pricing/index.html actually contains id="faq".

External checks: cache them, do not hammer someone else's server

Re-fetching every external link on every build is slow and rude. A site with two hundred outbound links does not need two hundred fresh requests for a commit that only fixes a typo in the footer. Cache the result, keyed by URL, and only re-check entries older than a set window.

import { existsSync, readFileSync, writeFileSync } from 'node:fs';

const CACHE_PATH = '.link-cache.json';
const CACHE_TTL_MS = 7 * 24 * 60 * 60 * 1000; // one week

function loadCache() {
  return existsSync(CACHE_PATH) ? JSON.parse(readFileSync(CACHE_PATH, 'utf8')) : {};
}

async function checkExternal(url, cache) {
  const cached = cache[url];
  if (cached && Date.now() - cached.checkedAt < CACHE_TTL_MS) {
    return cached.ok;
  }
  try {
    const res = await fetch(url, { method: 'HEAD', signal: AbortSignal.timeout(8000) });
    const ok = res.ok || res.status === 405; // some servers reject HEAD, treat 405 as inconclusive-pass
    cache[url] = { ok, checkedAt: Date.now() };
    return ok;
  } catch {
    cache[url] = { ok: false, checkedAt: Date.now() };
    return false;
  }
}

A HEAD request is enough to know whether a link resolves, and it costs the remote server far less than a full GET. Persisting the cache between runs, as a committed file or a CI cache artifact, means a flaky link gets flagged once, not on every commit for a week.

Fail on the right category

The crawler walks every page, resolves every link, and separates the two buckets before deciding whether the build lives or dies.

let brokenInternal = 0;
let brokenExternal = 0;

// ... after walking all files and resolving every link:
if (brokenInternal > 0) {
  console.error(`${brokenInternal} broken internal link(s). Failing build.`);
  process.exit(1);
}
if (brokenExternal > 0) {
  console.warn(`${brokenExternal} external link(s) did not resolve. Review before next release.`);
}
process.exit(0);

Wired into CI, this runs after the static build and before the deploy step, so a broken internal link never reaches production in the first place:

# .github/workflows/deploy.yml
- name: Build site
  run: npm run build
- name: Check links
  run: node scripts/crawl-links.mjs dist
- name: Deploy
  run: npm run deploy

The team building this kind of pipeline gate for client sites, including the redirect and link checks that go with a redesign, writes about the broader approach at nooralto.com.

Treating link rot as a build-time concern rather than a quarterly chore changes who finds the problem. Instead of a user hitting a dead page, or an audit six weeks late, the commit that introduced the break never merges.

Written by the team at Nooralto, a web and SEO studio working out of Agadir and Paris.

Built by Nooralto — Nooralto.

Structured data that survives a redesign

Nooralto1 — Fri, 25 Sep 2026 00:06:36 +0000

Structured data that survives a redesign

Structured data breaks in a specific, boring way. Someone hand-writes a <script type="application/ld+json"> block in the page template, ships it, and it works. Six months later the site gets a redesign: the breadcrumb component changes, a category gets renamed, the templating engine moves from server includes to a component framework. Nobody touches the JSON-LD block, because nobody remembers it exists. It keeps rendering, keeps validating as syntactically correct JSON, and keeps describing a page that no longer matches what a visitor sees.

Search Console reports the drift weeks later, if at all, as a drop in a rich result rather than an error. By then it is a mystery to debug instead of a diff to review.

The block is duplicated data, not markup

The underlying problem is that the JSON-LD is a second, hand-maintained copy of information the page already has. The breadcrumb trail exists once, to render the visible nav. It exists again, retyped, inside the schema block. Two copies drift the moment one of them changes and the other does not get the memo.

The fix is to stop writing the block by hand and generate it from the same data the page uses to render. One function, one input, two outputs: the visible breadcrumb nav and the JSON-LD, both built from the same array.

// schema/breadcrumb.js
function buildBreadcrumbSchema(breadcrumbs, baseUrl) {
  return {
    '@context': 'https://schema.org',
    '@type': 'BreadcrumbList',
    itemListElement: breadcrumbs.map((crumb, index) => ({
      '@type': 'ListItem',
      position: index + 1,
      name: crumb.label,
      item: new URL(crumb.path, baseUrl).toString(),
    })),
  };
}

module.exports = { buildBreadcrumbSchema };

breadcrumbs here is the exact array the nav component already receives as a prop. Rename a category and both outputs update from the same edit. There is no second place to remember.

Validate the shape before it ships

Generating the block from real data removes typos, but it does not stop someone from passing an empty array, or a crumb with no label, or a path that resolves to a relative URL instead of an absolute one. BreadcrumbList expects itemListElement as a non-empty list of ListItem entries, each with position, name, and item. A build step that checks that shape catches a broken page before it deploys instead of after Search Console notices.

// schema/validate.js
function assertValidBreadcrumbSchema(schema) {
  if (schema['@type'] !== 'BreadcrumbList') {
    throw new Error('expected @type BreadcrumbList');
  }
  if (!Array.isArray(schema.itemListElement) || schema.itemListElement.length === 0) {
    throw new Error('itemListElement must be a non-empty array');
  }
  schema.itemListElement.forEach((item, i) => {
    if (item['@type'] !== 'ListItem') throw new Error(`item ${i}: wrong @type`);
    if (typeof item.position !== 'number') throw new Error(`item ${i}: position must be a number`);
    if (typeof item.name !== 'string' || item.name.length === 0) {
      throw new Error(`item ${i}: missing name`);
    }
    if (typeof item.item !== 'string' || !/^https?:\/\//.test(item.item)) {
      throw new Error(`item ${i}: item must be an absolute URL`);
    }
  });
}

module.exports = { assertValidBreadcrumbSchema };

Call it right after buildBreadcrumbSchema, in the same build script that writes the page out. A page with a broken schema should fail the build, not reach staging.

Test the rendered output, not the generator

Unit-testing the generator function proves the function works. It does not prove the schema actually lands on the page, survives the templating layer, and matches what a crawler would parse out of the final HTML. That needs a test against the rendered output itself.

// test/breadcrumb-schema.test.js
const { test } = require('node:test');
const assert = require('node:assert/strict');
const { renderPage } = require('../render');

test('category page ships a valid BreadcrumbList', () => {
  const html = renderPage({
    type: 'category',
    slug: 'hiking-boots',
    breadcrumbs: [
      { label: 'Home', path: '/' },
      { label: 'Footwear', path: '/footwear' },
      { label: 'Hiking boots', path: '/footwear/hiking-boots' },
    ],
  });

  const match = html.match(/<script type="application\/ld\+json">([\s\S]*?)<\/script>/);
  assert.ok(match, 'no JSON-LD script tag found in rendered HTML');

  const schema = JSON.parse(match[1]);
  assert.equal(schema['@type'], 'BreadcrumbList');
  assert.equal(schema.itemListElement.length, 3);
  assert.equal(schema.itemListElement[2].name, 'Hiking boots');
  for (const item of schema.itemListElement) {
    assert.equal(typeof item.position, 'number');
    assert.ok(item.name.length > 0);
    assert.match(item.item, /^https:\/\//);
  }
});

This is the test that actually catches a redesign breaking things. If a future template swap drops the <script> tag entirely, or renames the prop the generator reads from, this fails on the next commit instead of on the next Search Console crawl.

Run one of these per page type that carries a schema block: product, article, FAQ, organization. Each type has its own required fields, so each gets its own assertions rather than one generic check.

Watch it after deploy too

A build-time test only proves the schema was correct at build time. A CDN caching an old bundle, a canary rollout serving two versions, or a third-party script mutating the DOM after load can still put stale or missing structured data in front of real crawlers. A lightweight periodic check, fetching a handful of key pages in production and re-running the same validator against whatever JSON-LD comes back, closes that gap without needing a full monitoring platform.

We wire this kind of build-time validation into new builds at Nooralto, so the schema block stops being a thing someone remembers to update by hand.

Structured data earns its keep when it is generated, not authored. Treat it as a projection of the page's own data, test that projection like any other output, and a redesign stops being a threat to it.

Written by the team at Nooralto, a web and SEO studio working out of Agadir and Paris.

Built by Nooralto — Nooralto.

Why your pages are crawled but not indexed

Nooralto1 — Fri, 25 Sep 2026 00:01:18 +0000

Why your pages are crawled but not indexed

"Crawled, currently not indexed" in Search Console gets treated as one problem with one fix,
usually "publish better content." The status covers several distinct failure modes, and content
quality is only one of them. The other three are almost always visible in the server response
itself, if anyone actually diffs what Googlebot receives against what a browser receives.

What "crawled but not indexed" actually means

Google fetched the URL, read the response, and made a deliberate decision not to add it to the
index. That is different from "discovered, not crawled", which is a budget or robots issue, and
different from a canonical replacing the URL with another one Google chose to index instead. The
Search Console UI collapses these into similar-looking rows. The API is more precise, and it is the
only practical way to check hundreds of URLs without clicking through the UI one at a time.

Querying status through the API

The URL Inspection API exposes the same data the UI shows for a single URL, built for automation.
Each call needs the property's verified siteUrl and the full inspectionUrl, sent to
urlInspection.index.inspect, which maps to POST /v1/urlInspection/index:inspect on the Search
Console API.

const { google } = require('googleapis');

async function inspectUrl(auth, siteUrl, inspectionUrl) {
  const searchconsole = google.searchconsole({ version: 'v1', auth });
  const res = await searchconsole.urlInspection.index.inspect({
    requestBody: { siteUrl, inspectionUrl },
  });
  const result = res.data.inspectionResult.indexStatusResult;
  return {
    url: inspectionUrl,
    verdict: result.verdict,               // PASS, PARTIAL, FAIL, NEUTRAL
    coverageState: result.coverageState,    // e.g. "Crawled - currently not indexed"
    lastCrawlTime: result.lastCrawlTime,
    googleCanonical: result.googleCanonical,
    userCanonical: result.userCanonical,
  };
}

The quota on this endpoint is small, so a full-site sweep needs to run as a slow batch rather than
a loop firing as fast as the client allows. Space the calls, and cache the results, since a page's
status does not move minute to minute.

The two canonical fields are the first thing worth comparing. When googleCanonical and
userCanonical disagree, Google decided the site's own canonical tag was wrong and picked a
different URL to index in its place. That alone explains a large share of "crawled, not indexed"
rows, and it needs no further diagnosis beyond fixing the tag.

When the tag is correct but the server still lies

If the canonical fields agree and the page still is not indexed, the next check is whether
Googlebot and an ordinary visitor are looking at the same document. Some setups serve different
HTML by user agent, deliberately or by accident, through a caching layer or a bot-protection rule
that treats crawlers differently from everyone else.

#!/usr/bin/env bash
# Compare what Googlebot fetches against what a browser fetches
URL="$1"

curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  -o googlebot.html -w "googlebot: %{http_code}\n" "$URL"

curl -s -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36" \
  -o browser.html -w "browser:   %{http_code}\n" "$URL"

diff <(grep -o '<title>.*</title>' googlebot.html) \
     <(grep -o '<title>.*</title>' browser.html)

A status code mismatch is easy to catch this way. A content mismatch hiding inside two identical
200 responses is the one that survives for months, because nothing in the logs looks like an
error.

The failure that produces no error at all

JavaScript-rendered content is the quieter version of the same problem. Googlebot fetches the
initial HTML, queues the page for rendering, executes the scripts, and only then sees the final
DOM. If a script throws, if a third-party dependency times out, or if the content depends on a
client-side fetch that the render sandbox blocks, the rendered page ends up thinner than the one a
visitor sees, with an HTTP 200 at every step along the way. There is no error to alert on. The
only way to catch it is to render the page the way the crawler does and diff the result against the
server-side output, the same comparison as above, run against the rendered DOM rather than the raw
response.

Redirect chains as a slow leak

A URL that resolves through two or three redirects before reaching its final destination usually
still gets indexed, but it competes for crawl budget against everything else on the domain, and
each additional hop is another place for a canonical or a status code to quietly diverge from what
was intended. Checking chain length is a short loop built on curl -I --location-trusted with
manual redirect handling, and it is worth running across the whole URL list on the same cadence as
the nooralto.com technical audits that catch
this alongside the canonical and rendering checks above.

Reading the four checks together

None of these checks needs the content rewritten first. Canonical agreement, user-agent parity,
rendered-DOM parity and redirect chain length are structural facts about the response, and they
answer whether Google is capable of indexing the page before the conversation moves to whether the
page deserves to be. Running the content-quality argument before ruling these out wastes a sprint
on the wrong hypothesis.

Written by the team at Nooralto, a web and SEO studio working out of Agadir and Paris.

Internal linking as a data structure

Nooralto1 — Fri, 25 Sep 2026 00:01:05 +0000

Internal linking as a data structure

Most internal linking work happens by hand: an editor remembers a related page and drops a link
at the bottom of a post. That works until the site passes a few hundred URLs, at which point
nobody remembers what links to what, and pages start going dark without anyone noticing.

The fix is to stop treating internal links as content and start treating them as a graph. Every
URL is a node. Every <a href> pointing at another URL on the same domain is a directed edge.
Once the site is represented that way, orphan pages, link depth and missing connections become
computable properties instead of things an editor has to remember.

Building the node list from the sitemap

The sitemap is the fastest way to get every URL the site claims exists, but it does not tell you
what links to what. Parse it first to get the full node set, then crawl the HTML to get the edges.

import { XMLParser } from 'fast-xml-parser';

async function loadSitemapUrls(sitemapUrl) {
  const xml = await fetch(sitemapUrl).then(r => r.text());
  const parser = new XMLParser();
  const doc = parser.parse(xml);
  const entries = doc.urlset?.url ?? [];
  const list = Array.isArray(entries) ? entries : [entries];
  return list.map(e => new URL(e.loc).pathname);
}

If the sitemap is an index of sitemaps, recurse into sitemapindex.sitemap the same way before
returning the flat list.

Building the edge list from the HTML

For each URL, fetch the rendered HTML (or the pre-render output, if the site is a SPA) and extract
every internal anchor. This is where most homegrown link audits stop, at a flat list of "page X
links to page Y". That list is already an adjacency table; the next steps just query it properly.

import * as cheerio from 'cheerio';

async function extractLinks(pathname, baseUrl) {
  const html = await fetch(new URL(pathname, baseUrl)).then(r => r.text());
  const $ = cheerio.load(html);
  const targets = new Set();
  $('a[href]').each((_, el) => {
    const href = $(el).attr('href');
    try {
      const u = new URL(href, baseUrl);
      if (u.origin === baseUrl && !targets.has(u.pathname)) {
        targets.add(u.pathname);
      }
    } catch { /* mailto:, tel:, javascript: ignored */ }
  });
  return [...targets];
}

async function buildGraph(urls, baseUrl) {
  const adjacency = new Map(urls.map(u => [u, []]));
  for (const url of urls) {
    const links = await extractLinks(url, baseUrl);
    adjacency.set(url, links.filter(l => adjacency.has(l)));
  }
  return adjacency;
}

The filter on the last line matters: keep only edges that land on a node already in the sitemap.
Links to unlisted URLs are a separate problem, usually a stale sitemap or a page that was deleted
without removing its incoming links.

Depth: a breadth-first search, nothing more

"How many clicks from the home page" is the standard proxy for how much authority a page is
likely to receive, and it is a textbook BFS.

function computeDepth(adjacency, root = '/') {
  const depth = new Map([[root, 0]]);
  const queue = [root];
  while (queue.length) {
    const current = queue.shift();
    for (const next of adjacency.get(current) ?? []) {
      if (!depth.has(next)) {
        depth.set(next, depth.get(current) + 1);
        queue.push(next);
      }
    }
  }
  return depth;
}

Any node from the sitemap that never appears in depth after this runs is unreachable by internal
links alone, no matter what the sitemap says about it. That is a stronger signal than a manual page
review will ever give: the page exists, but nothing on the site walks a visitor, or a crawler, to
it.

Orphans and isolated clusters

An orphan page is any node absent from depth. A subtler failure is a connected component that
never touches the root at all: a cluster of pages linking to each other whose only inbound link
came from a page that is itself unreachable.

function findOrphans(allUrls, depth) {
  return allUrls.filter(u => !depth.has(u));
}

Category pages and old campaign landing pages tend to end up here after a redesign quietly drops
the navigation block that used to reach them.

Generating links instead of placing them

Once the graph exists, the interesting move is to stop writing internal links by hand and generate
the missing ones at build time, from data rather than editorial memory: match each page's tags or
category against a candidate pool, cap how many new links a page can receive per build, and never
touch a page that already has structural exits from its template. The Nooralto
approach on client sites runs this as a build step, so the link set is versioned alongside the
content instead of living in an editor's head.

What to check on a schedule

Depth and orphan detection are cheap enough to run on every deploy, not once a year. A page that
used to sit three clicks from the home page and now sits at six, because a template change removed
a related-posts block, is a regression like any other, and it should fail a build the same way a
broken test does.

Written by the team at Nooralto, a web and SEO studio working out of Agadir and Paris.