DEV Community: AumCreate

Is your body text too small and too grey? An accessibility pass you can ship this week

AumCreate — Thu, 05 Nov 2026 04:29:01 +0000

A paragraph set at 13px in #999 on a white card looks calm in a mockup and is unreadable on a phone held outdoors. It also fails the contrast rule on its own: #999999 on white is 2.85:1.

None of what follows needs a redesign. It needs a floor — a minimum type size, a contrast rule, alt text written on purpose, and a focus ring nobody deletes.

Body text: pick a floor and keep it

Sixteen pixels is the absolute floor for body copy, and on a marketing page 18px reads better than 16. Secondary text — captions, metadata, form hints — should not go below 14px. Line height of 1.5 to 1.6 for anything longer than a sentence, and a measure of roughly 60 to 75 characters per line.

:root {
  --text: #1a1a1a;
  --text-muted: #5a5a5a;
  --step-0: 1.125rem;   /* 18px body */
  --step--1: 0.875rem;  /* 14px, the floor for secondary text */
}

body {
  font-size: var(--step-0);
  line-height: 1.6;
  color: var(--text);
  background: #ffffff;
}

.prose { max-width: 65ch; }

.meta {
  font-size: var(--step--1);
  color: var(--text-muted); /* ~6.9:1 on white */
}

Set the viewport without blocking zoom. user-scalable=no and maximum-scale=1 are the two values that stop people from enlarging text on a phone, and both still show up in starter templates.

<meta name="viewport" content="width=device-width, initial-scale=1">

Contrast: the numbers, and where they apply

Normal-size text needs 4.5:1 against its background. Large text — 24px and up, or 18.66px and up when bold — needs 3:1, and so do borders, icons and control outlines that carry meaning.

#767676 is the lightest grey that still clears 4.5:1 on white, at 4.54:1. One step lighter, #999999, is 2.85:1 and fails. That single pair of hex values explains most of the grey text on the web.

Things that get forgotten in the audit:

Placeholder text inside inputs is text. It needs to pass, and it also should not be the only label.
Text laid over a photo needs a solid or near-solid overlay behind it. A gradient that works on the desktop crop will not work on the mobile crop.
Links inside body copy need more than a color difference. Underline them, or the link disappears for anyone who cannot separate the two hues.
Required fields marked only in red are invisible to a chunk of your readers. Add the word.
Disabled buttons are exempt from the contrast rule, which makes "disable until valid" a bad pattern for a primary action. Let the button work, validate on submit, and show a readable message.

Check every color pair you actually ship, not the ones in the palette file — hover states, footer links on the dark band, and the text inside a filled button included.

Alt text is about purpose, not description

The question is not "what is in this picture" but "what is this picture doing here".

Decorative shapes, background flourishes, spacer images: alt="". An empty alt is not laziness; it is the instruction to skip the image.
A logo at the top of the page: the company name. Nothing else.
A product photo in a grid: the product and the variant a person would use to tell it apart — material, size, color.
An icon that is the only content of a link: the destination. Better still, put visible text next to it and drop the image from the accessible name.
A chart: a short alt naming what it plots, plus a real sentence or table of the numbers nearby. No alt text can carry a chart.
Captions and alt text should not repeat each other. If the caption says it, the alt does not need to.

Skip "image of" and "photo of" — the screen reader already says it is an image.

Keyboard: unplug the mouse and use the page

Tab from the address bar to the last link in the footer. Every stop should show a visible ring, in an order that matches the reading order, with nothing skipped and nothing trapped.

:focus-visible {
  outline: 3px solid #0b5fff; /* ~5.1:1 on white, clears the 3:1 non-text rule */
  outline-offset: 2px;
}

If a stylesheet in the project contains outline: none or outline: 0 on :focus, that is the bug. Replace it with the rule above rather than deleting the line and hoping.

A skip link is four lines and saves a keyboard user from tabbing through the whole nav on every page.

<a class="skip" href="#main">Skip to content</a>
<!-- ... -->
<main id="main">

.skip {
  position: absolute;
  left: 0;
  top: 0;
  transform: translateY(-120%);
  background: #ffffff;
  color: #1a1a1a;
  padding: 0.75rem 1rem;
  z-index: 100;
}

.skip:focus-visible { transform: translateY(0); }

Use <button> for anything that changes something on the page and <a href> for anything that goes somewhere. A clickable <div> is unreachable and unannounced; if you must keep it, add role="button", tabindex="0" and a keydown handler for Enter and Space, then ask why the <button> was not an option.

For dialogs, a native <dialog> opened with showModal() keeps focus inside and closes on Escape, which removes most of the hand-written focus-trap code. For menus and pickers, native <select> and <details> behave correctly with a keyboard by default. Hover-only navigation is unusable on a keyboard and on a touch screen at the same time.

Form errors have to be spoken

An error message that only changes color is an error message half your readers never receive. Tie the message to the field and let it be announced when it appears.

<label for="email">Email</label>
<input id="email" name="email" type="email" autocomplete="email"
       aria-describedby="email-error" aria-invalid="true">
<p id="email-error" role="alert">Enter an email address, for example name@company.com.</p>

Render the container empty on page load and fill it on submit. A message that is inserted into an existing live region is announced; one that arrives already populated inside freshly injected markup is less reliable.

Motion is the other thing people turn off. A short media query covers the carousels, the parallax and the smooth scrolling in one go.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

The pass to run before you publish

Work through this on the real staging site, not on a component library page.

Tab from the browser chrome to the end of the page with the mouse untouched. Visible ring at every stop, order matches the layout, no trap in a modal, no stop on a decorative element.
Zoom the browser to 200%. Nothing overlaps, nothing is clipped, no content disappears.
Narrow the window to 320px wide. No sideways page scroll — intentional scroll regions like a data table are fine.
Run a contrast checker on every text and background pair you ship, including placeholders, captions and hover states. 4.5:1 for body text, 3:1 for large text and for borders that carry meaning.
Turn on a screen reader for five minutes: NVDA on Windows, or VoiceOver on macOS with Cmd+F5. Listen to the navigation and the contact form. You are checking whether the labels make sense out loud, not whether every element is perfect.
Submit the contact form empty. The error is announced, the field is described by it, and focus lands somewhere sensible.
Open the accessibility panel in devtools and read the heading outline. One h1, no skipped levels, headings used for structure rather than for size.
Look at every image on the page: it either has alt text that says what it is for, or alt="".
Check tap targets on a phone. 24×24 CSS pixels is the floor with spacing, and primary actions want more room than that.
Finish with an automated scan and clear what it flags. It catches the mechanical failures — missing labels, low contrast, bad ARIA — and it cannot tell you whether your alt text is meaningful. That part is still yours.

A plugin and theme update routine: snapshot, pin, rehearse, then check what broke

AumCreate — Wed, 04 Nov 2026 08:13:19 +0000

Most update damage comes from the order of operations. Two plugins updated in the same minute, no snapshot, no record of the version that was running before — that turns a rollback of a few minutes into an evening of guessing which change broke checkout.

The routine below is what I would run on any WordPress site where an update can cost money. It isn't tied to a host or to a particular plugin.

Snapshot the files and the database together

Both, from the same moment. A file backup taken while an order is being written and a database dump taken ten minutes later can disagree about which plugins exist, and restoring that combination produces errors that look like a broken update.

wp db export db-$(date +%F-%H%M).sql
tar -czf uploads-$(date +%F-%H%M).tar.gz wp-content/uploads

A few details that matter more than the commands:

wp db export writes into the current directory. Move the dump off the server before you start updating.
Files means more than wp-content: wp-config.php, any .htaccess customisations, and drop-ins like an object cache file are part of what you are restoring.
A host-level snapshot is convenient, but find the restore button before you need it. Do one restore onto a copy, once, and note how long it took.
Sanity-check the dump: grep -c 'CREATE TABLE' db-*.sql should be a plausible number, and the file size shouldn't be a few kilobytes.

If the site takes orders, switch on maintenance mode for the duration of the dump so nothing writes mid-export, then switch it off.

Pin the versions you can't afford to lose

Record what is running before you change it:

wp plugin list --fields=name,status,version --format=csv > plugins-before.csv
wp theme list  --fields=name,status,version --format=csv > themes-before.csv

Keep the previous zip for anything that touches checkout, authentication, or page rendering. WP-CLI can put an exact version back:

wp plugin install <slug> --version=<x.y.z> --force

And stop those plugins from updating themselves while you sleep:

add_filter( 'auto_update_plugin', function ( $update, $item ) {
    $pinned = [ 'your-plugin-slug', 'another-plugin-slug' ];
    return in_array( $item->slug ?? '', $pinned, true ) ? false : $update;
}, 10, 2 );

Themes take the same arguments through auto_update_theme. Core is controlled separately by the WP_AUTO_UPDATE_CORE constant, where minor-only is usually the sensible setting.

Pinning is not the same as never updating. A pinned plugin still gets updated — on your schedule, with the old zip within reach.

Rehearse on a copy carrying production data

A staging site with three sample pages won't reproduce the failure you care about. Clone the production database and the plugin set, then:

wp plugin update --all --dry-run

The dry run lists what would change and touches nothing. Run it for real on the copy afterwards, and click through the paths that earn money: add to cart, checkout, the contact form, login, search.

Watch two logs while you click:

tail -f wp-content/debug.log
tail -f "$(php -r 'echo ini_get("error_log");')"

debug.log only exists when WP_DEBUG and WP_DEBUG_LOG are on. Turn them on for the copy, and keep WP_DEBUG_DISPLAY off so warnings don't land in the rendered page.

Update in batches — core, then plugins, then the theme — with a check between each. When something breaks you want to know which batch caused it, and "all at once" throws that information away.

Check the things that fail quietly

Some breakage is loud: a white screen, a fatal in the log. The rest is subtle, and it surfaces days later as a missing order or a form that never emailed anyone.

Forms: submit one and confirm the entry reached the database or the inbox.
Checkout: a complete test order, including the confirmation email.
Login and password reset.
The REST endpoint a block or theme depends on: curl -s -o /dev/null -w '%{http_code}' "$(wp option get home)/wp-json/".
Sitemap and feeds: curl -sI "$(wp option get home)/wp-sitemap.xml" | head -n 1.
Cron: wp cron event list. Updates occasionally reschedule or drop events, and a missed task shows up later as stale imports or no email.
Caches: page cache, object cache, CDN. Purge everything after the last batch — a stale cached page hides both the fix and the failure.
Database version: if core asks for an upgrade, snapshot again immediately before wp core update-db.
Image sizes: if a plugin changed its registered sizes, thumbnails may need regenerating.

Diffing the CSVs answers "what actually changed" faster than scrolling the admin:

wp plugin list --fields=name,status,version --format=csv > plugins-after.csv
diff plugins-before.csv plugins-after.csv

Roll back files and database together

Plugin updates run database migrations. Restoring only the plugin folder can leave the database ahead of the code, which shows up as missing tables or a fatal on the next request.

wp db import db-YYYY-MM-DD-HHMM.sql
wp plugin install <slug> --version=<x.y.z> --force

That restore discards everything written after the dump was taken — which is exactly why the snapshot goes immediately before the update, inside the maintenance window, and not the night before.

If the site genuinely can't go down, the fallback is to restore files only and then check whether the plugin's migration is safe to re-run. That's a per-plugin judgement call, and a decent argument for preferring plugins that don't migrate on update in the first place.

A routine short enough to run every time

A procedure you skip under time pressure is worse than no procedure. The version that fits in ten minutes:

Export the database and archive uploads; move both off the server.
Write plugin and theme versions to CSV.
Update on the copy first, then click through forms, checkout, login and search.
Update production in the same order, one batch at a time, in a low-traffic window.
Purge caches; check the error log, cron, sitemap and REST endpoint.
Keep the previous zips and the dump until the next round of updates.

Nothing here is clever. It's the ordering that saves the evening, not the tooling.

When an extra llms.txt or schema plugin is worth it next to the SEO plugin you already run

AumCreate — Wed, 04 Nov 2026 08:08:35 +0000

A page that emits two Organization nodes with different @id values is the most common symptom of two plugins describing the same business. The graph becomes ambiguous: a consumer has to guess which node is the subject of the page, and any property that appears on only one of them may be read as missing.

The same test decides whether an llms.txt plugin is redundant. If nothing on the site serves that path today, a plugin that adds it is the first producer, not a second one. If two things register the route, one file is served and neither admin screen tells you which one answered.

So: read the published output first, then decide what to install.

Find out what the page already publishes

Counting blocks is a start:

curl -s https://example.com/about/ | grep -c 'application/ld+json'

A count tells you how many blocks exist, not what is inside them. This script walks every block, follows @graph, and groups nodes by @type:

<?php
// scan-jsonld.php — list every JSON-LD node on a page and flag duplicate @type entries.
$url = $argv[1] ?? null;
if ( ! $url ) {
    fwrite( STDERR, 'usage: php scan-jsonld.php https://example.com/page/' . PHP_EOL );
    exit( 1 );
}

$ch = curl_init( $url );
curl_setopt_array( $ch, [
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_FOLLOWLOCATION => true,
    CURLOPT_TIMEOUT        => 20,
] );
$html = curl_exec( $ch );
if ( false === $html ) {
    fwrite( STDERR, curl_error( $ch ) . PHP_EOL );
    exit( 1 );
}
curl_close( $ch );

preg_match_all( '#<script[^>]*application/ld\+json[^>]*>(.*?)</script>#is', $html, $matches );

$nodes = [];
$walk  = function ( $node, $src ) use ( &$walk, &$nodes ) {
    if ( ! is_array( $node ) ) {
        return;
    }
    if ( isset( $node['@graph'] ) && is_array( $node['@graph'] ) ) {
        foreach ( $node['@graph'] as $child ) {
            $walk( $child, $src );
        }
        return;
    }
    if ( isset( $node['@type'] ) ) {
        $nodes[] = [
            'type' => implode( '|', (array) $node['@type'] ),
            'id'   => $node['@id'] ?? '(none)',
            'src'  => $src,
        ];
    }
    foreach ( $node as $value ) {
        if ( is_array( $value ) ) {
            $walk( $value, $src );
        }
    }
};

foreach ( $matches[1] as $i => $raw ) {
    $data = json_decode( trim( $raw ), true );
    if ( ! is_array( $data ) ) {
        echo 'block ' . $i . ': not valid JSON' . PHP_EOL;
        continue;
    }
    $walk( $data, 'block ' . $i );
}

$byType = [];
foreach ( $nodes as $node ) {
    $byType[ $node['type'] ][] = $node;
}

foreach ( $byType as $type => $list ) {
    $ids  = array_unique( array_column( $list, 'id' ) );
    $flag = count( $ids ) > 1 ? '  <-- same @type, different @id' : '';
    printf( '%-26s %d node(s)  ids: %s%s' . PHP_EOL, $type, count( $list ), implode( ', ', $ids ), $flag );
}

Run it against a handful of representative URLs: home, a service page, a product page, a post, an archive. Duplicates are rarely site-wide. A theme that injects BreadcrumbList on posts plus a plugin that injects it everywhere produces two nodes on some templates and one on the rest, which is why testing only the home page hides it.

llms.txt and sitemaps need the same treatment:

curl -sI https://example.com/llms.txt | head -n 1        # 200 means something already serves it
curl -s https://example.com/robots.txt | grep -i '^sitemap'

Two Sitemap: lines pointing at different indexes is noisy but rarely harmful. Two blocks declaring WebSite with different @id values is the case worth fixing.

What real duplication looks like

Same @type, different @id: two entities where there should be one. Remove one source.
Same @type, same @id, conflicting properties (telephone, address, price): worse, because one of the values is now simply wrong and you can't tell which from the outside.
A BreadcrumbList that doesn't match the visible breadcrumb: a rendering problem that also leaks into search results.
An Article node whose dateModified no human edited.

A node that only one source produces is not duplication, even if the plugin you already run is supposed to cover that type. Configuration differs per site; the HTML is the ground truth, not the feature list.

Where a second plugin earns its place

The type you need isn't modelled. A full-suite SEO plugin covers the common vocabulary — organization, website, article, breadcrumb, sometimes product — and typically has no field for Service with areaServed, no way to express product variants as separate Offer nodes, and nothing that ties an FAQPage to the questions actually visible on the page. If your pages describe services by region, that gap is the reason to add something.

You need per-page control. One graph for every URL of a post type is convenient until two pages need different structures. A plugin that lets you edit the node for a single page solves that without touching the rest.

Nothing serves llms.txt. It is a proposed convention rather than a ratified standard, and no major crawler documents that it reads one, so the effect is unproven. Publishing it costs nothing and conflicts with nothing as long as it is the only producer.

Where it just duplicates

If the new plugin emits Organization, WebSite, BreadcrumbList and Article on the same URLs the suite already covers, you are adding weight and a second set of facts. Meta descriptions and XML sitemaps behave the same way: two plugins writing a description tag means one wins per page by hook priority, and nobody documented which.

A rough map — verify against your own output rather than trusting the middle column:

Need	Full-suite SEO plugin	Extra plugin justified?
Title, meta description, canonical	yes	no
XML sitemap	yes	no
Organization / WebSite	usually	no
BreadcrumbList	usually	no
Article basics	yes	no
`Service` with `areaServed`	rarely	yes
Product variants as separate offers	partial	maybe
Per-page node editing	limited	yes
`llms.txt`	usually not	yes, if nothing else serves it

If you add one, remove the overlap first

Re-run the scanner and save the output.
Switch off the overlapping module in one of the two. Most full-suite plugins let you disable their schema output; one that doesn't is a reason to prefer a different arrangement.
Re-run the scanner. The node count should drop and nothing you need should disappear.
Install the new plugin, re-run the scanner, compare the list of @type values rather than the counts.

One plugin that works this shape is AumViso: it emits llms.txt, structured data, a sitemap, meta tags and internal links. If your suite already produces the sitemap and the meta tags, the honest reason to install it is the structured data and the llms.txt, and you would turn the suite's schema module off in the same session.

The scanner is the whole test. Same URL, same script, before and after. If the second run shows the same @type list with more nodes, the plugin added nothing; if it shows a type that wasn't there before, it did its job.

WP-Cron vs system cron: what to check when WordPress scheduled tasks start missing

AumCreate — Tue, 03 Nov 2026 06:51:10 +0000

A renewal email lands four hours after the invoice goes out. A nightly import stops for six days and nobody notices until the numbers are wrong. Nothing in the logs says cron failed, because nothing failed in a way that logs.

WP-Cron is a due-check, not a scheduler. On each page request WordPress looks at the cron option, finds events whose timestamp has passed, and fires a non-blocking loopback request to wp-cron.php to run them. No traffic, no runs. That is the whole failure mode, and it covers most "the plugin stopped working" reports.

Confirm the event is late

wp cron event list --fields=hook,next_run_gmt,recurrence,args

next_run_gmt is UTC. Compare it with date -u, not with the clock in your site's timezone settings. An event with a next_run_gmt hours in the past is overdue. An event that is missing from the list was never scheduled, which is a different bug: plugin inactive, scheduling hooked to admin-only code, or something called wp_clear_scheduled_hook.

Look at the spawn lock

Before spawning, WordPress writes a doing_cron transient and holds it for WP_CRON_LOCK_TIMEOUT seconds, 60 by default. That lock is why a dead run doesn't cause every page load to start another one, and it is also why a dead run silences the next minute of attempts.

wp transient get doing_cron

A value that persists across several minutes means something is still holding it. Clearing it is safe once you know no run is in flight:

wp transient delete doing_cron

Check that spawning is enabled

wp config get DISABLE_WP_CRON
wp config get ALTERNATE_WP_CRON

DISABLE_WP_CRON set to true means page loads never trigger anything. That is correct when a system cron exists, and a silent outage when someone copied the setting from a tutorial and the crontab line never got added.

Test the loopback request

The spawn is an HTTP request from the server to itself. Basic auth, a maintenance plugin, a WAF rule on wp-cron.php, or a hosts-file mismatch kills it while the site still looks fine to visitors.

wp eval 'var_dump( wp_remote_retrieve_response_code( wp_remote_get( add_query_arg( "nocache", time(), site_url( "wp-cron.php" ) ), array( "timeout" => 5 ) ) ) );'

You want 200. This call does run any due events, which is harmless and a little useful. Tools → Site Health → Info has a loopback test that tells you the same thing without typing.

Find the other scheduler

crontab -l
sudo -u www-data crontab -l

Hosting panels add entries under their own user. Two crons calling wp cron event run --due-now is survivable, since an event only fires once per due timestamp, but two crons with different paths or one running as root against a different wp-config.php produces behaviour that looks random.

Switch

In wp-config.php, above the "stop editing" line:

define( 'DISABLE_WP_CRON', true );

In the crontab of the user that owns the files, not root:

*/5 * * * * flock -n /var/lock/example-wp-cron.lock -c 'cd /var/www/example.com/current && /usr/local/bin/wp cron event run --due-now --quiet'

What each part is doing:

cd into the install so wp finds wp-config.php without a --path flag.
flock -n returns immediately when the previous run is still going. Without it a slow run overlaps the next one and two processes write the same options.
Run as the site user. --allow-root works and leaves root-owned files in wp-content, which breaks uploads and plugin updates later.
Five minutes is a reasonable default. Each invocation boots WordPress, so a small site has a floor of roughly one run per minute.
A time-critical hook can get its own tighter line (wp cron event run my_hook) without changing the general interval.

Without shell access, a panel cron or an external cron service hitting a URL works:

https://example.com/wp-cron.php?doing_wp_cron=1699999999

Include a changing value in the query string or a CDN may serve a cached response indefinitely. Test it once and confirm a known event moved in wp cron event list; whether a direct hit to wp-cron.php still executes events while DISABLE_WP_CRON is on is not something to assume across versions and hosts.

Shared hosting without SSH, a panel cron nobody documented, a site that changed hands with no notes: in any of those the switch above takes longer than ten minutes, because it turns into a conversation with the host. Most support desks will add a crontab line if you hand them the exact command and the path. Moving to a host that gives you shell access is the other clean route, and it is a reasonable moment to have the site rebuilt properly: AumCreate does a fixed-scope WordPress deployment onto hosting you already own — template installed, every page rewritten with your copy, a preview link, one round of changes, then live, with a one-page note on how to edit content — for a one-time $399 (what the handover covers). Domain and hosting stay in your name and are billed by those providers, and there is no annual fee from us. It is a build, so if the cron tasks are the actual problem, ask for the scheduled events and who owns them to be written into the handover.

What breaks quietly afterwards

Queues that are not WP-Cron. WooCommerce and a long list of plugins put background work into Action Scheduler, which keeps its own tables and its own runner. wp cron event run --due-now does not drain that queue. Check the scheduled-actions screen after the switch, and add a deterministic trigger if you want one:

*/5 * * * * cd /var/www/example.com/current && /usr/local/bin/wp action-scheduler run --quiet

Long events blocking the batch. wp cron event run --due-now runs due events in a single process. One event stuck on a remote API eats the run and everything behind it waits for the next tick. Batch heavy work — 50 rows at a time, store a cursor, let the next invocation pick up the rest.

Make a missed run visible

Record the last successful run, and take a lock so a slow run cannot double-process:

add_action( 'myplugin_sync', function () {
    global $wpdb;

    $got = $wpdb->get_var(
        $wpdb->prepare( 'SELECT GET_LOCK(%s, %d)', 'myplugin_sync', 5 )
    );

    if ( '1' !== (string) $got ) {
        return; // another run holds the lock
    }

    try {
        // work here
        update_option( 'myplugin_last_sync', time(), false );
    } finally {
        $wpdb->query( $wpdb->prepare( 'SELECT RELEASE_LOCK(%s)', 'myplugin_sync' ) );
    }
} );

GET_LOCK is per database connection, so it releases when the process dies, including a hard kill. That makes it a better fit than an option flag that survives a crash and blocks the next ten runs.

Expose the age of that timestamp to whatever already watches the site:

add_action( 'rest_api_init', function () {
    register_rest_route( 'health/v1', '/cron', array(
        'methods'             => 'GET',
        'permission_callback' => '__return_true',
        'callback'            => function () {
            $last = (int) get_option( 'myplugin_last_sync', 0 );
            $age  = $last ? time() - $last : PHP_INT_MAX;

            return new WP_REST_Response(
                array( 'last_sync_age_seconds' => $age ),
                $age < 3600 ? 200 : 500
            );
        },
    ) );
} );

A monitor expecting 200 from that endpoint every five minutes catches the failure wp cron event list never shows: a cron entry that exists, runs on schedule, and does nothing useful. Pair it with an attempt counter and a cap, so a task that fails permanently lands somewhere readable instead of retrying forever with no record.

The switch is ten minutes of work. The part that needs thinking is which events deserve a system cron at all: anything that moves money, sends mail, or expires access belongs there; a weekly transient cleanup does not.

How many fields does an inquiry form need before sales can quote?

AumCreate — Tue, 03 Nov 2026 04:55:54 +0000

A buyer types "please send price for 500 pcs" into a contact form late at night. The next morning a rep replies with a list of questions: which model, which country, when do you need it. The buyer answers two days later, or doesn't, and somewhere in between a competitor sent a number.

Making the form longer does not fix that, and neither does making it shorter. The useful question is narrower: which answers does a price depend on? Everything else can move into the reply.

Write the quote before you design the form

Get the person who actually quotes prices to produce three quotes for three recent inquiries, from scratch, without reopening the original email thread. Note every question they had to answer in order to reach a number. That list is your field list, and it is usually shorter than the form you already have.

It tends to come out as five items: what the item is, how many, where it ships, when it is needed, and an address that reaches a human. Everything else is comfort.

Give each candidate field a job

Question	Can the quote be produced without it?	First form?
Model or part number	No	Required
Quantity	No	Required
Delivery country and city	No — freight and tax move with it	Required
Rough timing	Sometimes	Dropdown, with an empty default
Working email address	No — there is nowhere to send the quote	Required
Company name	Only if you sell to companies exclusively	Required in B2B, optional otherwise
Contact name	No	Optional
Phone	No	Optional, never required
Free-text message	No	Optional, marked as optional
Budget	No — and asking too early costs the inquiry	Leave out
How did you hear about us	No	Leave out, or ask on the thank-you page
Tax or VAT number	No, that is an onboarding step	Leave out

The test for anything not on this list: if a blank answer would not stop the quote, it belongs in the reply, not on the form. Budget is the one field people insist on and buyers rarely answer honestly at first contact — if the number matters, ask after you have shown you understand the requirement.

Friction is rarely the field count

Six clean fields convert better than four bad ones. What kills inquiries:

A required phone number, on a form used by buyers in another country who do not want a call. A country dropdown with every territory in it, on a phone. A required company name when the buyer is an individual sourcing one sample. A field that only accepts uploads, which fail on mobile data and give no feedback when they do. Validation that clears the form on error. A blank thank-you page that does not say what happens next.

Every one of those is fixable without removing a question sales needs.

The form itself

Plain HTML, labels outside the inputs, input types that bring up the right keyboard on a phone:

<form action="/inquiry" method="post">
  <label for="email">Work email</label>
  <input id="email" name="email" type="email" autocomplete="email" required>

  <label for="company">Company <span>(optional)</span></label>
  <input id="company" name="company" type="text" autocomplete="organization">

  <label for="item">Model or part number</label>
  <input id="item" name="item" type="text" required>

  <label for="qty">Quantity</label>
  <input id="qty" name="qty" type="text" inputmode="numeric" autocomplete="off" required>

  <label for="dest">Delivery country and city</label>
  <input id="dest" name="dest" type="text" autocomplete="address-level2" required>

  <label for="when">When do you need it?</label>
  <select id="when" name="when">
    <option value="">Not sure yet</option>
    <option value="2w">Within two weeks</option>
    <option value="1m">This month</option>
    <option value="1q">This quarter</option>
  </select>

  <label for="notes">Anything else <span>(optional)</span></label>
  <textarea id="notes" name="notes" rows="4"></textarea>

  <p class="hp" aria-hidden="true">
    <label for="website">Website</label>
    <input id="website" name="website" type="text" tabindex="-1" autocomplete="off">
  </p>

  <button type="submit">Get a quote</button>
</form>

<style>
  .hp { position: absolute; left: -9999px; }
</style>

Notes on the choices. Quantity is type="text" with inputmode="numeric" rather than type="number", because number inputs change value on a scroll wheel and reject the way people write quantities. The timing dropdown has an empty first option so nobody is pushed into a false answer. The honeypot replaces a captcha: reject the submission server-side if website is not empty, and skip the whole puzzle that real buyers fail on a train.

If a file matters — a drawing, a bill of materials, a photo of a damaged part — ask for it in the confirmation, not on the form. By then the buyer has committed, and a link is easier than a failing upload widget.

Keep the form to one column on every screen size. Preserve what was typed when a validation error fires, and put the error next to the field that caused it.

Say what happens after submit

The thank-you page is part of the form. Two things belong on it: what you will send and when, and the one or two details that would speed it up if they have them to hand. "We reply within one working day with a price and lead time. If you have a drawing or a target price, send it to this address and we will include it."

That single paragraph removes most of the second round trip without adding a field.

Read the messages for a fortnight

The free-text box is a research tool. Read every message that arrives for two weeks and count how often the same question appears — "do you ship to X", "is this the same as model Y". Anything asked repeatedly is either a missing field, a missing explanation on the product page, or a shipping restriction nobody wrote down. Fix the page before you fix the form.

What to measure afterwards

The share of inquiries where the first reply could be the quote itself, with no clarifying email. And the share that reach your order system without anyone re-keying or chasing a missing detail. If both stay flat after trimming fields, the problem is upstream of the form — usually the product pages do not state what the buyer needs to know to describe their requirement.

Hand this to whoever builds it

Required: model or part number, quantity, delivery country and city, email.
Optional and visibly marked optional: company, name, free text.
No required phone number, no required budget, no captcha, no required upload.
Timing as a dropdown with an honest "not sure yet" option.
Validation that keeps the typed values, with the error beside the field.
A thank-you page that states the reply time and asks for attachments by return.
Someone reads the free-text box weekly for the first month.

One page, one question: how to structure headings and FAQ blocks so an answer engine can quote a passage

AumCreate — Mon, 02 Nov 2026 04:38:43 +0000

Someone asks an assistant a question. The assistant fetches a handful of pages, splits them into chunks, and keeps the chunk that looks like an answer. If your page buries the answer under four paragraphs of context, the chunk that survives is the context, and you don't get quoted.

The unit that gets retrieved and quoted is the passage, not the page. Everything below follows from that: write pages whose passages survive being cut out and read alone.

What a chunk looks like by the time it reaches the model

Retrieval systems split HTML into pieces of a few hundred tokens, usually cutting near headings. The piece arrives without your navigation, without the paragraph before it, without the table of contents. A sentence that begins "as mentioned above" or "this approach" arrives with no referent.

Test any paragraph by asking: if I paste only this block into an empty document, does it still say something true and complete? If not, it is a weak chunk.

Should a page answer one question or several?

One. The heading, the opening line and the FAQ should all point at the same question, phrased the way a person would type it. A page that answers "how much does a 3-bedroom move cost in Singapore" will not also answer "how do I pack a kitchen" well enough to be quoted for either.

Splitting is not a rule about word count. A short page answering two questions is worse than two short pages, because the retrieval system may pull half of the first answer and match it against the second question.

When two of your pages answer the same question, merge them. Duplicate answers compete with each other and neither becomes the reference.

The first sentence under a heading has to be the answer

Readers who scan and extractors that chunk both want the answer in the first sentence, before the justification.

Which version would you quote?

## Why is my WordPress site slow?

Performance is a broad topic and there are many factors to consider. In this
article we will look at several areas that affect how quickly a page loads,
starting with the hosting environment and then moving on to caching...

## Why is a WordPress site slow?

A WordPress page is slow when PHP rebuilds the page on every request and the
finished HTML is never stored. The usual causes are no page cache, an expensive
uncached query on each load, and images served at full resolution.

The second version answers inside one sentence and stays understandable out of context. The first version only announces that an answer is coming.

Delete the announcement paragraph entirely rather than shortening it. Openings like "in this article we will cover" have no value as a chunk.

Write chunks that name their own subject

A passage that gets pulled out of your page loses its title. Pronouns lose their reference and the chunk becomes useless.

Instead of "it handles retries automatically", write "the queue handles retries automatically".
Instead of "this approach scales", write "the queue-based import scales".
Instead of "most people prefer the second option", name what the second option is.

Numbers need units and a date. "5 working days" beats "fast turnaround". "Checked in October 2026" tells the reader the number has an owner and an expiry, and both are things a model can repeat without distorting them.

How should FAQ blocks be arranged?

An FAQ block is a set of small, self-contained answer chunks, and it works when you treat each item as its own page in miniature.

One question per item, phrased the way it gets searched. "Do you charge a yearly fee?" beats "Pricing notes".
The first sentence answers. Detail, caveats, exceptions come after, and they can be dropped without breaking the answer.
No nested sub-questions. If an item needs a follow-up question, it needs its own page.
No filler openings. "Great question!" and "That's a common concern" are the first thing a chunk carries and the first thing a reader skips.
Only questions someone actually asked. Six invented questions that pad a section produce six useless chunks and dilute the ones that matter.
Keep the answers in the HTML source. Content injected by JavaScript after load is invisible to a fetcher that does not run scripts. A <details> element is fine because the text is in the markup; a tab widget that loads its panel by request is not.

<h2>Frequently asked questions</h2>

<details>
  <summary>Does a heading have to be phrased as a question?</summary>
  <p>No, but a question heading matches how people search and gives the
  extractor a clean boundary. "Pricing" is a weaker heading than "How much
  does a delivery cost?"</p>
</details>

<details>
  <summary>Can an extractor read text inside a collapsed element?</summary>
  <p>Yes, when the text is in the HTML. A details element ships its content in
  the markup even while collapsed; a panel fetched by JavaScript after load
  does not.</p>
</details>

Structured data for FAQ is optional. Markup can describe a page, but the text is what gets extracted and repeated. Adding schema to thin answers produces well-labelled thin answers.

A page skeleton you can copy

# How much does X cost?          <- the question, in the searcher's words

One or two sentences that answer it, with the number, the currency and
what is included. No preamble.

## What is included in the price?

The first sentence states the inclusion. Then the detail.

## What changes the price?

Named factors, each with a short explanation.

## How do I start?

The concrete next action, one step, not a menu of five.

## Frequently asked questions

Four to six items, each answer-first and self-contained.

Notice the heading is not "Pricing". A heading that repeats the question gives the extractor a clean boundary and gives the reader a reason to stop scrolling.

Small things that break otherwise good passages

Comparisons that say "the first option" without naming it, in a table where the column headers were cut off with the chunk.
Answers that begin with "it depends" and never reach the actual answer. Put the dependency in the second sentence.
Numbers with no date and no scope. A figure that was true last year, or true only for one project size, gets repeated as if it were general.
A single page that is really six questions stapled together, each half-answered.
Repeated boilerplate under every heading, so that three different chunks all start with the same sentence about the company.

Before you publish, read the first sentence of every section on its own

Scroll through the page and read only the first sentence under each heading, with the heading attached. If those sentences form a coherent answer to the page's question, the page will survive chunking. If any of them needs the preceding paragraph to make sense, rewrite it.

That check takes two minutes and catches most of what makes a page unquotable.

Cleaning a product CSV before import: encoding, image URLs, variant rows, and finding the line that broke

AumCreate — Mon, 02 Nov 2026 04:33:32 +0000

An 800-row product sheet looks like a 20-minute import until the importer stops somewhere past the halfway mark and says the SKU is duplicated. It does not say which line. That is usually the moment people start deleting rows until something passes.

Most of those failures come from the file, not the store. The encoding, the price column, the image URL column, the variation rows and the SKU column account for nearly all of them. Clean those in a script first and the import turns into a non-event.

Everything below is plain Python 3 and works on any CSV you are about to feed into an admin importer. Only the column names are WooCommerce-flavoured.

pip install charset-normalizer requests

Read the file as bytes and let the library guess

A CSV exported from Excel on a Chinese or Japanese Windows machine is GB18030, not UTF-8. A CSV exported from Excel on macOS often has a UTF-8 BOM. Open a GB18030 file with encoding="utf-8" and you get either a UnicodeDecodeError on line 400 or, worse, mojibake that imports fine and renders as Ã¤Â¸Â on the product page three days later.

import csv, io, re, sys, unicodedata
from pathlib import Path
from urllib.parse import urlparse
from charset_normalizer import from_bytes
import requests

ZERO_WIDTH = dict.fromkeys(map(ord, "\u200b\u200c\u200d\ufeff"), None)
ODD_SPACES = {"\u00a0": " ", "\u2007": " ", "\u202f": " ", "\u3000": " "}

def decode_any(path):
    raw = Path(path).read_bytes()
    guess = from_bytes(raw).best()
    if guess is None:
        sys.exit(f"no usable encoding for {path}")
    return str(guess).lstrip("\ufeff")   # drop the BOM if there is one

def clean(value):
    if value is None:
        return ""
    v = unicodedata.normalize("NFKC", value)
    v = v.translate(ZERO_WIDTH)
    for bad, good in ODD_SPACES.items():
        v = v.replace(bad, good)
    return re.sub(r"[ \t\r\n]+", " ", v).strip()

NFKC folds full-width letters and digits to ASCII, which is what you want in a SKU (ＡＢ－１２ becomes AB-12). It also rewrites some typographic punctuation, so skip it on the description column if the client cares about curly quotes.

Non-breaking spaces and zero-width characters are the other silent killer. They survive copy-paste from a chat app, look identical on screen, and make SKU == "AB-12" false for no visible reason.

Prices need one decision: which separator is the decimal one

1.299,00, 1,299.00, 1299, $1299.00, 1299,00 EUR all arrive in the same file when several people filled in the sheet. The rule that survives contact with real data: if both separators appear, the rightmost one is the decimal separator. If only one appears and it is followed by exactly three digits, it is a thousands separator. Everything else is decimal.

def parse_price(raw):
    s = clean(raw).replace(" ", "")
    if not s:
        return None, "empty"
    s = re.sub(r"[^\d.,\-]", "", s)        # drop currency symbols and letters
    neg = s.startswith("-")
    s = s.lstrip("-")
    if not any(c.isdigit() for c in s):
        return None, f"no digits in {raw!r}"

    last_dot, last_comma = s.rfind("."), s.rfind(",")
    if last_dot > -1 and last_comma > -1:
        dec = "." if last_dot > last_comma else ","
        thou = "," if dec == "." else "."
    elif last_dot > -1 or last_comma > -1:
        sep = "." if last_dot > -1 else ","
        digits_after = len(s) - s.rfind(sep) - 1
        if s.count(sep) == 1 and digits_after in (1, 2):
            dec, thou = sep, None
        else:
            dec, thou = None, sep
    else:
        dec = thou = None

    if thou:
        s = s.replace(thou, "")
    if dec and dec != ".":
        s = s.replace(dec, ".")
    try:
        value = round(float(s), 2)
    except ValueError:
        return None, f"unparsable {raw!r}"
    return (-value if neg else value), None

Run this before the import and eyeball the rows where the input contained a separator. A 1.299 that should have been 1.299 euros and got read as 1299 is a refund, not a rounding error.

Image URLs fail in ways a browser hides

A URL that opens in your browser can still break the import. The three that bite: a content-type that is text/html because the host serves a "hotlinking not allowed" page, an unescaped space from a filename like red shoe.jpg, and an http URL on an https store (mixed content, image silently dropped).

Check with a HEAD request, fall back to a streamed GET because plenty of CDNs answer HEAD with 403 or 405, and cache the result so 40 variations sharing one parent image do not make 40 requests.

SESSION = requests.Session()
SESSION.headers["User-Agent"] = "csv-preflight/1.0"

def check_image(url, cache):
    if url in cache:
        return cache[url]
    problem = None
    p = urlparse(url)
    if p.scheme not in ("http", "https"):
        problem = "not an absolute http(s) URL"
    elif " " in url:
        problem = "unescaped space in URL"
    elif "." not in p.netloc:
        problem = "host has no dot"
    else:
        try:
            r = SESSION.head(url, timeout=10, allow_redirects=True)
            if r.status_code in (403, 405, 501):
                r = SESSION.get(url, timeout=10, stream=True, allow_redirects=True)
                r.close()
            if r.status_code >= 400:
                problem = f"HTTP {r.status_code}"
            else:
                ctype = r.headers.get("content-type", "").split(";")[0].strip().lower()
                if not ctype.startswith("image/"):
                    problem = f"content-type {ctype or 'missing'}"
        except requests.RequestException as exc:
            problem = exc.__class__.__name__   # Timeout, SSLError, TooManyRedirects
    cache[url] = problem
    return problem

Split gallery columns on commas before checking, and strip quotes around each part — "img1.jpg, img2.jpg" pasted out of a spreadsheet carries both.

Variation rows are where the SKU logic breaks

A variable product in a CSV is two kinds of row: the parent (Type=variable) and one row per combination (Type=variation) whose Parent column holds the parent SKU. Four things go wrong, in this order of frequency:

a variation points at a parent SKU that exists in the shop but not in the file, or was renamed in one place only;
two rows share a SKU, usually the parent's price row copied down into the variations;
the variation has no attribute value, so the importer creates a combination that cannot be selected on the front end;
the parent has no price and no variation has one either, so the product imports at 0.

Build the parent index first, then validate the variations against it. Do not validate in file order — a variation can legally sit above its parent.

def check_skus_and_variants(rows, header):
    problems, seen, parents = [], {}, {}
    for line, row in rows:
        sku = row.get("SKU", "")
        if sku:
            if sku in seen:
                problems.append((line, "SKU", sku, f"duplicate, first seen on line {seen[sku]}"))
            else:
                seen[sku] = line
        if row.get("Type", "").lower() == "variable" and sku:
            parents[sku] = line

    attr_cols = [h for h in header if h.lower().startswith("attribute")]
    for line, row in rows:
        if row.get("Type", "").lower() != "variation":
            continue
        parent = row.get("Parent", "")
        if parent and parent not in parents:
            problems.append((line, "Parent", parent, "parent SKU not present in this file"))
        if attr_cols and not any(row.get(c) for c in attr_cols):
            problems.append((line, "", "", "variation has no attribute value"))
        if not row.get("Regular price") and not parents.get(parent):
            problems.append((line, "Regular price", "", "no price on the variation"))
    return problems

Finding the line that actually failed

The importer's error message counts data rows, starting at 1 for the first row after the header. csv.reader.line_num counts physical lines in the file, starting at 1 for the header. If any field contains a line break inside quotes — a description with <br> typed as a real newline — the two numbers drift apart and you end up staring at the wrong record.

Report both, and let the reader pick.

There is a second, sharper signal: the column count. An unquoted comma inside a description pushes every later field one column to the right, so the row arrives with more fields than the header. Catch that before anything else, because every field-level check after it is meaningless.

def load_rows(path):
    text = decode_any(path)
    reader = csv.reader(io.StringIO(text))
    header = [clean(h) for h in next(reader)]
    good, bad = [], []
    for rec in reader:
        line = reader.line_num
        if not any(clean(c) for c in rec):
            continue
        if len(rec) != len(header):
            bad.append((line, "", "", f"expected {len(header)} columns, got {len(rec)}"))
            continue
        good.append((line, {h: clean(v) for h, v in zip(header, rec)}))
    return header, good, bad

def main(src, report="import-report.csv"):
    header, rows, problems = load_rows(src)
    problems += check_skus_and_variants(rows, header)
    cache = {}
    for line, row in rows:
        for col in header:
            if "image" not in col.lower():
                continue
            for url in [u.strip().strip('"') for u in row.get(col, "").split(",") if u.strip()]:
                why = check_image(url, cache)
                if why:
                    problems.append((line, col, url, why))
        if "price" in " ".join(header).lower() and row.get("Regular price"):
            _, why = parse_price(row["Regular price"])
            if why:
                problems.append((line, "Regular price", row["Regular price"], why))

    problems.sort()
    with open(report, "w", newline="", encoding="utf-8") as fh:
        w = csv.writer(fh)
        w.writerow(["physical_line", "column", "value", "problem"])
        w.writerows(problems)
    print(f"{len(rows)} clean rows, {len(problems)} problems -> {report}")

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

A note on what the report means. physical_line is the line in the file; the importer's row number is that minus one, minus any multiline rows above it. Sort the report by physical_line, open the sheet, and look at the columns named — nine times out of ten the value in the value column is visibly wrong once you are looking at the right cell.

Fix the sheet, re-export as UTF-8 with all fields quoted, run the script again until the report is empty, then import. A clean file imports in one pass and, more importantly, the data that lands in the database is the same data you reviewed.

We publish free WordPress plugins (translation, structured data, crawler visibility, digital-goods checkout) at https://aumcreate.com/plugins?utm_source=devto&utm_medium=content&utm_campaign=devto-csv-import-field-cleaning

Auditing wp_options autoload, revisions and transients before you clean a WordPress database

AumCreate — Mon, 02 Nov 2026 04:28:26 +0000

Cleaning a WordPress database is easy to do in the wrong order. The commands that drop revisions and expired transients are one line each, and none of them ask whether the option you just un-autoloaded is read by a plugin on every page load. Audit first, delete second — that order is what lets you undo a mistake without restoring last night's backup.

Everything below runs against a real database. Substitute your own table prefix wherever wp_ appears.

Take a copy you can actually restore from

wp db export pre-cleanup-$(date +%F).sql

Move that file off the server. A dump sitting in the same web root is not a backup. If the site takes inquiries, do this at the quietest hour you have; a dump of a busy InnoDB database is a long read and it holds locks you don't want during business hours.

Then look at where the space actually is:

wp db size --tables --human-readable

SELECT table_name,
       ROUND((data_length + index_length) / 1024 / 1024, 1) AS mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 15;

If wp_options is near the top of that list on a site with a few hundred posts, the autoload column is the first thing to open.

wp_options: find out what ships with every request

Autoloaded options are read into memory on every request — front end, admin, REST, cron. A large autoloaded payload is a cost you pay whether the visitor needed it or not.

Newer schemas store autoload as on / off / auto-on / auto-off; older ones use yes / no. Check which you have before writing anything else:

SELECT autoload, COUNT(*) FROM wp_options GROUP BY autoload;

Then the total, and the biggest individual rows:

SELECT COUNT(*) AS options,
       ROUND(SUM(LENGTH(option_value)) / 1024, 1) AS kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on');

SELECT option_name,
       LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on')
ORDER BY bytes DESC
LIMIT 25;

For every row near the top you need three answers before changing anything: who owns it, whether it is read on the front end, and whether it regenerates itself.

grep -rn "the_option_name" wp-content/plugins wp-content/themes --include=*.php | head -20

Crude, but it answers the ownership question faster than reading a settings screen. If nothing matches, the option probably belongs to something uninstalled. Note it down and handle it in a second pass, after you have confirmed the site still works without it.

Turning autoload off is one update:

UPDATE wp_options SET autoload = 'off' WHERE option_name = 'the_option_name';

On a schema that still uses yes / no, write 'no'. Then flush:

wp cache flush

Re-run the total query and write the number down. Come back in a week — some plugins call update_option() on save and autoload can get set back on, so an option you turned off today may be back on after the next settings save. Worth knowing before you tell anyone the database is clean.

Revisions: measure by parent, not by total

A revision is a full copy of post_content in wp_posts. The count is less interesting than which posts own the copies.

SELECT COUNT(*) AS revisions,
       ROUND(SUM(LENGTH(post_content)) / 1024 / 1024, 1) AS mb
FROM wp_posts
WHERE post_type = 'revision';

SELECT r.post_parent AS post_id,
       p.post_title,
       COUNT(*) AS revisions,
       ROUND(SUM(LENGTH(r.post_content)) / 1024 / 1024, 1) AS mb
FROM wp_posts r
JOIN wp_posts p ON p.ID = r.post_parent
WHERE r.post_type = 'revision'
GROUP BY r.post_parent, p.post_title
ORDER BY mb DESC
LIMIT 20;

The top of that list is usually one or two long pages that get edited on every sales call. Before deleting anything, note two things:

Autosaves are stored as revisions too, identified by autosave in post_name. Deleting them does not touch published content, but it will surprise someone who has a draft open in the editor right now.
Custom post types and page-builder content keep their revisions in the same table, and are deleted the same way.

Delete in chunks so a large site does not exhaust memory or hit command-line argument limits:

while ids=$(wp post list --post_type=revision --format=ids --posts_per_page=200) && [ -n "$ids" ]; do
  wp post delete $ids --force
done

Cap future growth in wp-config.php:

define( 'WP_POST_REVISIONS', 5 );

That is a ceiling going forward. It does not remove what already exists, and it does not shrink the table — see the rebuild step at the end.

Transients: expired is safe, orphaned needs a decision

With no persistent object cache, transients live in wp_options as a _transient_<key> row plus a _transient_timeout_<key> row.

Count the expired ones:

SELECT COUNT(*) AS expired
FROM wp_options
WHERE option_name LIKE '\_transient\_timeout\_%'
  AND option_value < UNIX_TIMESTAMP();

Those are dead. WordPress clears them on its own schedule eventually; doing it now is safe:

wp transient delete --expired

Orphans are a different case — a value row with no timeout row at all:

SELECT COUNT(*) AS orphans
FROM wp_options o
WHERE o.option_name LIKE '\_transient\_%'
  AND o.option_name NOT LIKE '\_transient\_timeout\_%'
  AND NOT EXISTS (
    SELECT 1 FROM wp_options t
    WHERE t.option_name = CONCAT('_transient_timeout_', SUBSTRING(o.option_name, 12))
  );

Some were set without an expiry on purpose; some were left behind by a plugin that stopped writing to them. Deleting an orphan costs a cache miss the next time the plugin asks for the value, so the risk is low. If the number is large, find the owning prefix first — a plugin that keeps state in a no-expiry transient may behave differently right after the flush.

One check worth doing before you count these as waste: if the site runs Redis or Memcached, transients live in the object cache and these option rows are leftovers from before it was enabled. Flush and re-count to find out which world you are in.

wp cache flush

Rebuild the tables and verify

Deleting rows does not shrink the files. On InnoDB tables with a lot of free space, a rebuild reclaims it:

wp db optimize

This is not free. It rebuilds tables and takes time proportional to their size, so run it in a quiet window rather than at 2pm on a Tuesday.

Verify in this order:

wp option get siteurl
wp post list --post_type=page --fields=ID,post_title,post_status --posts_per_page=5
wp plugin list --status=active

Then in a browser, with a cache-busting query string: the home page, the page that had the most revisions, the inquiry or checkout form, and the admin dashboard. Watch the browser console for 404s, and open the settings screen of any plugin whose options you touched — that is where a wrongly deleted option shows up first.

Re-measure what you measured at the start:

SELECT COUNT(*) AS options,
       ROUND(SUM(LENGTH(option_value)) / 1024, 1) AS kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on');

Compare the two numbers. If the autoloaded total barely moved, the database was not your bottleneck and the next place to look is the slow query log, not another cleanup plugin.

The order that holds up: export, measure, identify the owner, change one class of rows at a time, verify the front end, rebuild, re-measure. Every step you skip is a step you redo from the backup.

If you want an outside read on what the site actually serves after the rebuild — broken assets, redirect chains, pages that no longer resolve — a site check at https://aumcreate.com/tools/site-check?utm_source=devto&utm_medium=content&utm_campaign=devto-wp-db-cleanup-order covers that from the visitor's side.

Which AI crawler is actually loading your server, and which one to rate-limit first

AumCreate — Sun, 01 Nov 2026 14:28:31 +0000

A site slows down, someone opens the access log, sees a wall of bot requests, and blocks them. Two days later the site is slow again and the list of bots has changed. The step that got skipped is the one that makes the answer stable: pricing what each crawler actually costs before you change anything.

This is the sequence I'd run on a WordPress box, and it works the same on any LAMP-style stack. It ends with a ranked list and one change to make, instead of a firewall full of guesses.

First check whether the web tier is even the bottleneck

cat /proc/loadavg
top -b -n1 -o %CPU | head -15

If the top CPU consumers are php-fpm and mysqld, HTTP requests caused this and the access log holds the evidence. If you see heavy kswapd, kcompactd, or %wa near 100, memory or disk is the problem — rate-limiting a crawler buys you a few days and nothing else. Look at the PHP-FPM pool as well. All children busy with a non-zero listen queue means requests are queueing, so continue. Idle children while load is high means the time is going somewhere else: cron, a CLI import, a backup job.

Get timing into the log

The default combined format gives you bytes and user agent but no duration, and duration is what separates a crawler making 200 cheap requests from one making 200 expensive ones.

nginx:

log_format main_ext '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" "$http_user_agent" '
                    'rt=$request_time';

access_log /var/log/nginx/access.log main_ext;

nginx -t && systemctl reload nginx

Apache: add %D to a custom LogFormat; it's the request duration in microseconds. Existing lines keep the old format, so give it an hour before reading.

Slice by user agent

Both nginx and Apache combined quote the request, the referer and the user agent. That makes " a reliable field separator, and the UA the sixth field:

awk -F'"' '{print $6}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

You'll get the usual mix: uptime monitors, search engines, your own scripts, and whatever AI crawlers your content attracted. Note the candidates, then move to cost.

Price each bot in worker seconds

Hit counts flatter crawlers that are noisy but cheap. Multiply by time instead:

awk -F'"' '
  {
    split($3, s, " ")        # s[2]=status, s[3]=body bytes
    ua = $6
    rt = $NF; sub(/^rt=/, "", rt)
    hits[ua]++
    bytes[ua] += s[3]
    secs[ua]  += rt
  }
  END {
    for (u in hits)
      printf "%10.1f %8d %13d  %s\n", secs[u], hits[u], bytes[u], u
  }' /var/log/nginx/access.log | sort -rn | head -20

Columns: seconds of request handling, hits, bytes served, user agent. A crawler at 8,000 hits and 40 seconds is background noise. One at 900 hits and 600 seconds is your problem, and it's probably hitting something expensive.

If the file is too large to parse in one pass, sample it:

shuf -n 500000 access.log > sample.log

Ratios survive sampling. Absolute counts don't, so don't quote them anywhere.

Look at the paths the top bot requests

awk -F'"' '$6 ~ /BotName/ {split($2, r, " "); print r[2]}' access.log \
  | sort | uniq -c | sort -rn | head -20

Replace BotName with a token from the previous step. What you're looking for:

Search results, faceted filters, cart and checkout URLs. Uncacheable, database-backed, and often the entire cost.
Pagination deep in the archive, or tag pages that nothing links to.
A single URL requested thousands of times, which is a crawler bug or a redirect loop more than a load problem.

If the expensive paths are the same across several bots, fix the paths first. It's a smaller change and it applies to every visitor.

Prove causality before you throttle

A user agent is a claim, and a throttle is cheap to test. Short-circuit one UA temporarily:

# temporary, inside the server block
if ($http_user_agent ~* "BotName") {
    return 403;
}

Reload, wait 20–30 minutes, and compare load average, PHP-FPM queue depth and database CPU against the same window before the change. If nothing moved, that bot wasn't the cause and you can drop the rule. Then check whether the UA is genuine rather than a scraper wearing it:

dig +short -x 203.0.113.10        # reverse lookup
dig +short crawl.example.com      # forward lookup, should return the same IP

Forward-confirmed reverse DNS is what separates the real crawler from someone running curl with a copied header. It matters most right before you write a permanent rule.

Order to act in

Order	Change	Fixes	How to verify
1	Cache or deny the expensive paths	Every bot at once	Re-run the path query, seconds column drops
2	Per-bot rate limit	The highest-cost bot only	Hit count falls, 429s appear for that UA
3	`robots.txt` rules	Crawlers that honour it	Read the log again after 24–48h
4	Firewall block	One persistent offender	Requests stop entirely

A per-UA rate limit looks like this:

map $http_user_agent $bot_key {
    default          "";
    ~*GPTBot         "gptbot";
    ~*ClaudeBot      "claudebot";
}

limit_req_zone $bot_key zone=ai_bots:10m rate=30r/m;

server {
    limit_req zone=ai_bots burst=20 nodelay;
    limit_req_status 429;
    # ...
}

Requests with an empty key aren't counted, so ordinary visitors are untouched. Use the tokens you actually saw in your own log, not the two above. If your build exposes $limit_req_status, add it to the log format and you can confirm the limits are firing instead of assuming.

robots.txt sits third for a reason: it's advisory. Some crawlers honour it, some don't, and the only way to know which happened is to read the log a day later. Write the file, then verify it, rather than reporting it as done.

Close the loop with the numbers you started with

Run the cost query again over a window after the change. You want the same shape of answer as before: which UA is first, and how many seconds it now costs. If the top entry has changed, you fixed the last problem and this one was already there waiting.

Wrap the whole sequence in a small script and keep it. One command that prints seconds, hits and bytes per user agent, sorted, is worth more than a firewall rule nobody can explain six months from now.

If you'd rather not maintain the parser: AumCrawl is a free plugin that records which AI crawlers are hitting a WordPress site and lets you allow or block them individually from the admin. It sits next to the log work above rather than replacing it — the log is still what tells you what each bot costs.

Splitting B2B export keyword research by part number, application and industry

AumCreate — Sun, 01 Nov 2026 14:25:04 +0000

The output of this process is a spreadsheet: one row per query, one column for the vocabulary the query belongs to, one for where you found it, one for the page it maps to, one for what to do with it. Everything below is about filling those columns honestly. The research part is mostly deciding which rows deserve a page of their own.

The vocabulary column decides everything else

B2B buyers search in one of three vocabularies, and which one they use tells you where they are in the buying process and what kind of page can answer them.

Vocabulary	What the buyer already knows	Query shape	Page that answers it
Part number	the exact part	`ABC-1234`, `ABC1234 datasheet`, `replacement for XYZ-45`	family page with parameters, variants, documents
Application	the job the part has to do	`600V mosfet for LED driver`, `valve for 180C steam line`	application page with an app note or a test
Industry	the regulated world they sell into	`automotive grade ...`, `medical device ...`	segment page with certifications and references

Sort every row before you do anything else. A list that mixes the three gets prioritised by whatever has the biggest volume number, which is usually the vaguest query and the hardest page to write.

Part numbers: the shortest path from search to enquiry

Start by collecting the strings. They're already written down somewhere:

your catalogue and order history
customer emails and RFQs — the exact string is in there, punctuation included
distributor spreadsheets and price lists
the cross-reference tables printed in datasheets, both yours and the ones for parts you replace
drawings, packaging, spare-part lists

Judging demand works differently here. Volume tools return zero or a dash for most of these strings, and that means "not enough data", not "nobody searches". Better evidence, in rough order of strength: the string appears in an actual enquiry; the string shows impressions in your search console query report; a distributor asked for it by name.

Normalise before you count. The same part arrives as ABC 1234, ABC-1234, abc1234, ABC/1234. Counted raw, that's four queries where there is one.

With a CSV that has a query column, this groups strings into families and shows you where the spellings cluster:

import csv
import re
import sys
from collections import defaultdict

FAMILY = re.compile(r"([A-Za-z]{1,5})[\s\-_/]?(\d{2,6})")


def family(query):
    match = FAMILY.search(query)
    if not match:
        return None
    prefix, digits = match.group(1).upper(), match.group(2)
    return f"{prefix}{digits[:3]}"


rows = list(csv.DictReader(open(sys.argv[1], encoding="utf-8")))
by_family = defaultdict(set)
for row in rows:
    key = family(row["query"])
    if key:
        by_family[key].add(row["query"].strip().lower())

for key, queries in sorted(by_family.items(), key=lambda item: -len(item[1])):
    sample = "; ".join(sorted(queries)[:5])
    print(f"{key}\t{len(queries)}\t{sample}")

The heuristic is deliberately crude — prefixes like LED or AC will pull unrelated strings together, so read the output before you build anything from it. What you're looking for is families with several distinct spellings. Those are the ones where buyers are already searching by part number. A family with exactly one spelling, and that spelling matches your internal code, is usually a string you invented.

A family earns its own page when you sell it, you can fill the page with parameters, variants and documents, and more than one spelling shows up. A single SKU with no documents belongs in a row of the family table, not on its own URL. Hundreds of near-identical pages end up competing with each other for the same query, which is worse than one complete page.

Applications: queries from buyers who don't know your part numbers

These buyers describe the job. The query pattern is a part type plus "for" or "used in" plus a condition: temperature, voltage, IP rating, package, certification.

Where they show up: support tickets, notes from sales calls, trade-show conversations, distributor application pages, industry forums, and the applications section of your own datasheets. That last one is underrated — it was written by engineers in the buyer's language rather than in your category tree.

Build a grid rather than a list. Applications down one side, constraints across the other.

Application	Constraint	Query example	Evidence you can show
LED driver	600 V, high switching frequency	`600v mosfet for led driver`	app note, efficiency curve
Steam line	180 °C continuous	`valve for 180c steam line`	test report
Battery charger	reverse polarity protection	—	nothing yet

Fill a cell only when there's a document, a test result, or a reference customer behind it. Empty cells are information: they tell you what to ask engineering for before you write anything.

An application phrase without proof belongs in a short FAQ block on the family page. Giving it its own URL produces a page that says the same thing as the family page in slightly different words, which helps nobody.

Industry: the vocabulary the buyer's regulator uses

Automotive, medical, lighting, appliance, industrial automation each have their own words for the same component, and those words come from standards and procurement departments, not from your product taxonomy. That's why industry rows often look unfamiliar when you first see them in a query report.

Industry queries are the vaguest and the most contested. One product page won't hold them. What holds them is a segment page — the parts you ship into that segment, the certifications, the documents, one or two references — with the family and application pages underneath it linking up. If you have no references in a segment, don't build the segment page yet; the page will be a paragraph of adjectives.

Before a term goes into the sheet, test it out loud: would a buyer say this on a phone call, or is it a literal translation of your internal category name? Translated category names are the most common source of rows that sit for a year with no impressions.

Ordering the work

Score each row on two things only: how specific the query is, and how much evidence you can put on the page. A row with zero evidence is a dead row regardless of how attractive the keyword looks.

Part-number families first if you sell by part number. The queries are narrow enough that one complete page can answer them, and the person searching already knows what they want.
Applications second. More reach, more work, and it needs documents you may not have yet.
Industry last, unless you already have references in that segment.

Monday: the first twenty rows

Take the top twenty rows by that score. For each one, write the single sentence that answers the query, exactly as it would appear on the page. If you can't write the sentence from material you already have, the row isn't a page — it's a request to engineering for a datasheet, a test, or a photo.

Two checks before anyone opens an editor:

Every row maps to a page, and every page has at least one row whose query a real buyer typed.
No two rows with the same intent map to different URLs. That's how a site ends up with three pages quietly competing for one search, and it's much cheaper to catch in the sheet than after publishing.

Internal linking order: which links to place first, and how to control the anchor text

AumCreate — Sun, 01 Nov 2026 14:21:09 +0000

A product page with 46 blog posts behind it and three internal links pointing at it. Two of those sat in the footer, so they appeared on all 46 pages and said the same thing 46 times. The third was in a post about a variant that no longer ships. Every post ended with four "related reading" links chosen by tag, so most of the blog's links pointed at other blog posts.

Nothing there was broken. The site just never had an order: links were added as pages were published, and nobody asked which page should be receiving them. Decide the order first, then choose the words — editing anchors on a link map you haven't settled on yet wastes the pass.

Put the target pages in a file first

Pick the pages that have to be found — the ones that answer a question someone types before they contact you. Somewhere between five and twelve. More than that and you spread the work so thin that nothing moves.

Write them one path per line:

/services/emergency-plumbing
/products/heat-exchanger-120
/guides/sizing-a-pressure-valve

Save it as priority.txt. The script at the bottom reads it.

Order the link types by what a single edit buys

Links from pages that already have weight. Pages with external backlinks or steady organic clicks have something to pass on. A link from one of those, in the body of the page, does work that a link from an orphaned post nobody visits doesn't. Find them in your search console's links report, or — with no backlink data — in the pages report sorted by clicks. Write the donor list next to each target before you touch anything.

Links between a target page and the pages that support it. The target links down to the detail pages: variants, pricing, documents, a case. Each detail page links back up in the body, not just in a breadcrumb. That's what makes a cluster readable — a crawler can see which page is the parent, and a reader can get from a specific question to the main offer without using the menu.

Links between sibling pages that answer the next question. Someone reading about a 120 kW unit asks about the 160 kW one. Someone reading about installation asks about maintenance. These cost almost nothing and they pick up the long-tail queries the parent page can't hold.

Work in that order: a couple of weeks of donor edits, then the cluster, then the siblings.

How many in-body links belong on a page

There's no published cap, and anyone quoting one is guessing. The constraint that bites is reader attention: past roughly one link per 100–150 words of body copy, the page reads like a directory and people stop following any of them.

Navigation and footer links don't belong in that count — they're template, not editorial. Which is also why they do less work than people expect.

Find the posts that don't link to the target

On WordPress, this returns published posts whose content never mentions the target path:

SELECT p.ID, p.post_title, p.post_date
FROM wp_posts p
WHERE p.post_type = 'post'
  AND p.post_status = 'publish'
  AND p.post_content NOT LIKE '%/services/emergency-plumbing%'
ORDER BY p.post_date DESC;

Run it in your DB client or with wp db query < missing-links.sql. Check one row before you trust the result: the editor stores absolute URLs, so the pattern has to match what's actually in post_content. If your permalinks carry a trailing slash, include it.

The output is a candidate list, not a to-do list. Pick the three or four posts that already get impressions for something adjacent to the target and edit those. The rest can wait.

Control the anchor text instead of the link count

The anchor is the part of a link that tells anything downstream what the target is about. Most sites spend it on "read more" or on the same three words repeated sitewide.

Anchor	What it carries	How often
Exact product or service term	the target's main query, unambiguously	once per target, from the strongest donor
Descriptive phrase lifted from the target's own H2	the specific question the target answers	the default; vary the phrasing per page
Sentence-natural ("a walkthrough of the sizing steps")	context from the sentence around it	wherever the sentence wants it
"click here", "read more", "this page"	nothing	replace on sight

Four rules that hold regardless of how ranking systems change:

One anchor, one URL. If two pages could both take the same phrase, one of them is the wrong target — usually the older, thinner one. Merge or choose.
Read the sentence with the link text spoken out loud. If the anchor only makes sense because it's blue and underlined, rewrite the sentence.
Pull anchors from the target page's own headings. If the target has an H2 "Sizing a pressure valve for a 3-inch line", that phrase beats your internal category name, because the page can actually answer it.
Use the exact term once, from the strongest donor, and vary it elsewhere. Ten identical anchors from ten pages read as one recommendation repeated, and you lose the vocabulary that would have told anything downstream what the page covers.

Never reuse one anchor for two different targets across the site. It splits the signal and it annoys readers who click the same words and land somewhere new.

Sitewide links: keep the template small

A link in the header appears on every crawlable URL. That's correct for humans — it's how people navigate — but it does very little to differentiate pages: links are processed per page, and the same target with the same anchor from 400 URLs is one anchor repeated.

Practically: keep the nav to the handful of pages a first-time visitor needs, keep the footer to policy and contact pages, and put the differentiation into body copy where the anchor can change per page.

Audit it with a script

This walks your sitemap, counts inbound internal links per path, and separates links inside <main> or <article> from nav and footer links. Standard library only, no dependencies.

#!/usr/bin/env python3
"""Internal link audit.
Usage: python3 audit.py https://example.com/sitemap.xml priority.txt > report.csv
"""
import csv
import re
import sys
import urllib.parse
import urllib.request
from collections import Counter, defaultdict
from html.parser import HTMLParser

SITE = "{0.scheme}://{0.netloc}".format(urllib.parse.urlsplit(sys.argv[1]))
HOST = urllib.parse.urlsplit(SITE).netloc
UA = "internal-link-audit/1.0"


class LinkParser(HTMLParser):
    MAIN = {"main", "article"}

    def __init__(self):
        super().__init__(convert_charrefs=True)
        self.links = []
        self._href = None
        self._text = []
        self._main = 0

    def handle_starttag(self, tag, attrs):
        if tag in self.MAIN:
            self._main += 1
        if tag == "a":
            href = dict(attrs).get("href")
            if href:
                self._href = href
                self._text = []

    def handle_data(self, data):
        if self._href is not None:
            self._text.append(data)

    def handle_endtag(self, tag):
        if tag == "a" and self._href is not None:
            text = " ".join("".join(self._text).split())
            self.links.append((self._href, text, self._main > 0))
            self._href = None
            self._text = []
        elif tag in self.MAIN and self._main:
            self._main -= 1


def fetch(url):
    req = urllib.request.Request(url, headers={"User-Agent": UA})
    with urllib.request.urlopen(req, timeout=30) as resp:
        body = resp.read()
        charset = resp.headers.get_content_charset() or "utf-8"
    return body.decode(charset, "replace")


def path_of(url):
    return urllib.parse.urlsplit(url).path.rstrip("/") or "/"


def internal_path(href, base):
    if href.startswith(("#", "mailto:", "tel:", "javascript:")):
        return None
    parts = urllib.parse.urlsplit(urllib.parse.urljoin(base, href))
    if parts.netloc != HOST:
        return None
    return parts.path.rstrip("/") or "/"


sitemap = sys.argv[1]
priority = {line.strip() for line in open(sys.argv[2], encoding="utf-8") if line.strip()}
paths = sorted({path_of(loc) for loc in re.findall(r"<loc>\s*(.*?)\s*</loc>", fetch(sitemap))})

inbound_body = Counter()
inbound_all = Counter()
anchors = defaultdict(Counter)

for path in paths:
    try:
        html = fetch(SITE + path)
    except Exception as exc:
        print(f"skip {path}: {exc}", file=sys.stderr)
        continue
    parser = LinkParser()
    parser.feed(html)
    for href, text, in_main in parser.links:
        target = internal_path(href, SITE + path)
        if target is None or target == path:
            continue
        inbound_all[target] += 1
        if in_main:
            inbound_body[target] += 1
            if text:
                anchors[target][text] += 1

rows = []
for path in sorted(set(paths) | priority):
    rows.append({
        "path": path,
        "priority": "yes" if path in priority else "",
        "in_body_inbound": inbound_body[path],
        "all_inbound": inbound_all[path],
        "top_anchors": " | ".join(f"{a} ({n})" for a, n in anchors[path].most_common(3)),
    })

rows.sort(key=lambda r: (r["priority"] != "yes", r["in_body_inbound"]))
writer = csv.DictWriter(sys.stdout, fieldnames=list(rows[0].keys()))
writer.writeheader()
writer.writerows(rows)

Run it with python3 audit.py https://example.com/sitemap.xml priority.txt > report.csv. It reads a flat sitemap; if yours is a sitemap index, expand the <loc> list first or point it at the child sitemap.

The sort puts priority pages with the lowest in-body inbound count at the top. Those rows are your donor-edit list, in order.

Two caveats worth knowing before you act on the numbers. Links injected by JavaScript won't show up — the script only sees what's in the HTML, so spot-check one page in the browser. And a path in priority.txt that isn't in the sitemap still gets a row, usually with zeros; that's often the most useful row on the sheet, because it means the page has no inbound links from anywhere the crawler reaches.

After the edits

Re-run the same script three weeks later and diff the report. Then look at whether the priority URL is indexed and whether it's picking up impressions for the phrase you used as its anchor. Give it weeks, not days — an internal link is a hint about structure, not a switch.

If you're on WordPress and would rather not maintain the script: AumViso handles sitemap output, schema and internal links, and it's free. I still run the audit above afterwards, because it counts what's actually in the rendered HTML, which is the only version that matters.

For me it comes down to this: a site with 46 pages and no link order is 46 pages competing to be noticed. A site with 46 pages and one decided order is a hierarchy. The difference is a few hours of editing, not a redesign.

How many pages a company site needs before launch, and what goes on each one

AumCreate — Sun, 01 Nov 2026 13:53:04 +0000

A template sitemap arrives with twelve entries on it, the domain is already bought, and the launch date is three weeks out. The useful question at that point is not how many pages a company site should have. It is which pages this particular sale requires, and what has to be true on each one before someone can act on it.

Working backwards from a page count gives you pages nobody maintains.

Let the purchase path set the floor, not the template

Four inputs decide the minimum: how a customer decides, the size of a typical deal, where trust has to come from, and whether the buying happens in one session or over several weeks.

Business shape	Pages that must exist at launch	Reasonable to add later
Local service, one offer, phone-first	Home, Contact	Separate service page, gallery
Quoted B2B, a few distinct offers	Home, one page per offer, About, Contact, legal	Process, compliance, case pages
Self-serve product	Home, product and pricing, docs or FAQ, Contact, legal	Comparison pages, changelog
Long cycle, high value	Home, offer pages, About, process, Contact, legal	Case studies, security page, team

Legal means whatever your jurisdiction requires — privacy notice, terms, and a company imprint where one is mandated. Those are not marketing pages and they are not optional.

The table is a starting position you argue with, not a rule. If a page sits in the "later" column and nobody can name the sentence that would go on it, it does not go on the list.

What has to be on each page before it goes live

Page	Its one job	Must contain before launch
Home	Say what this is, for whom, where, and what to do next	One sentence naming the offer and the customer; the primary action visible without scrolling; one concrete proof point; a link to contact
Offer page	Answer "can they do my version of this"	Who it is for, what is included, what is not, turnaround, what the buyer has to supply, next step
About	Give a reason to trust the people	Who runs it, where they operate, what they do not do, how to verify the claims
Contact	Remove the last excuse	A form that works, an email address, a phone number someone answers, hours, a response time you can keep
Legal	Keep you out of trouble	Privacy notice, terms, required registrations
Thank-you and 404	Catch people at the edges	Confirmation of what happens next; links back to the main offers

The first screen is not a slogan slot

Many home pages open with a positioning line and a stock photo. A visitor arriving from a search result needs three facts before anything else: what you sell, who it is for, and what the next step costs them in effort. Put those in the first paragraph, as plain text, in the words buyers use when they describe the problem.

One primary action. Two equally weighted buttons — "Contact us" next to "Download brochure" — split the decision and usually reduce both.

If geography matters, say where you serve in the first screen, not in the footer. If you work remotely and location does not matter, say that too, because a visitor who cannot tell will assume you are local to someone else.

When one offer deserves its own page

The default is one page per offer only if these hold:

A different buyer, or genuinely different questions from the same buyer.
Different proof is needed — a certificate, a lead time, a spec sheet the others do not have.
Enough to say to fill a page without padding. A screen and a half of real content is a fair bar.
Someone will maintain it.
People search for it under a different phrase than the parent offer.

Two or more failing means one page with anchored sections. Splitting because "more pages is better for SEO" produces thin pages that compete with each other for the same query, and they usually cannibalise rather than help. If you split later, use a URL that survives a redesign: /services/name, not /our-services-2026.

Filling the trust gap with no testimonials, cases or photos

Real options that require inventing nothing:

Publish the process step by step, including what you need from the customer and how long each step usually takes.
Say what you do not do. A page that excludes some work reads as more credible than one claiming everything.
Show real work with the client's written permission, even if it is one photo and a paragraph.
Give prices or ranges where the business allows it. "Contact us for pricing" costs you the visitors who only wanted a number.
Name the person responsible and how to reach them.
Link to things a reader can check independently — registration, certification, address, a partner's own site.

What you should never do is write your own testimonial, use a stock face captioned as a customer, or publish a case with figures you cannot back up. It reads fine until a buyer asks one question about it.

The pre-publish pass, page by page

The title contains the offer, in the buyer's words.
The first paragraph names who the page is for.
Exactly one primary action, repeated at the end.
No placeholder text, no "coming soon", no dead items in the menu.
The form was submitted end to end by a human and the confirmation email arrived.
Phone numbers are tappable; addresses are text, not baked into an image.
The page loads on a phone over a slow connection without the layout jumping.
There is a link to it from at least one other page.

Site-wide: a sitemap, a robots file that blocks nothing you need indexed, and analytics that record which page a form was submitted from — not only that a form was submitted.

Leaving room for page seven

Navigation that is a flat list of every page becomes a redesign the moment you add two. Group by what the buyer is trying to do and keep the top level short.

When you merge, split or rename after launch, redirect the old URL and keep the redirect. Internal links inside other pages are the usual thing that gets missed — the redirect works for search engines and for readers, but paragraphs that reference the old page still point at the old URL.

Deciding after launch on something other than taste

Give it a month, then read entrance data per page: which pages people land on, which pages nobody enters, which pages earn internal clicks, and where form submissions start and stop.

A page with no entrances, no internal links and no form activity is a candidate to merge into a page that does have traffic, not to delete. A page where two different questions keep showing up in the same visit is a candidate to split. New pages should come from a question you have seen more than once, not from a keyword tool's estimate.

Set a review date when you launch. Otherwise the next decision about the site gets made by whoever is annoyed enough to raise it, and by then the fix is a redesign.