DEV Community: Benjamin Oats

Bulk-Generated Alt Text Still Needs a Spot-Check

Benjamin Oats — Tue, 25 Aug 2026 07:11:54 +0000

Bulk-Generated Alt Text Still Needs a Spot-Check

Generate alt text for 300 images at once and you're not going to read all 300 descriptions before saving — nobody does, and expecting otherwise is exactly why review steps get skipped entirely on large batches. The honest question isn't "will I review every one," it's "can I catch the errors that matter without reviewing every one." That's a sampling problem, not a diligence problem, and it has a workable answer.

Why "review everything" fails at bulk scale

A checklist for reviewing individual alt text — is it accurate, is it the right length, does it avoid keyword stuffing, does it skip "image of" — works fine for one image, or ten. Applied to 300, it turns into either hours of reading nearly identical sentences, or a review step that exists on paper but never actually happens because nobody has the hours. Most bulk alt text failures on real WordPress sites trace back to exactly this: a full-review policy that was realistic for a dozen images and got quietly abandoned once the batch size hit the hundreds.

The fix isn't lowering the bar on quality, it's changing what "reviewed" means for a large batch — from "every item read" to "enough items read, chosen the right way, to catch a systemic problem before it ships to all 300."

What a bulk batch actually gets wrong

AI alt text generation doesn't fail randomly across a batch — it tends to fail in clusters, which is exactly what makes sampling effective:

One bad prompt pattern, many bad outputs. If the generator misreads a specific product category — say, it consistently describes a colour variant wrong across a whole product line — that error shows up on every image in that line, not scattered randomly through the batch. Sampling a handful from each distinct image category catches this faster than random sampling across the whole set.

Context the generator didn't have. Images with the same visual content but a different meaning depending on where they sit — a WooCommerce variation swatch versus the same swatch used as a decorative background elsewhere — often get near-identical alt text from a generator working off pixels alone. That's a per-context error, not a per-image one.

A handful of genuinely broken images. Corrupted files, placeholder graphics, or images that failed to load properly during generation sometimes produce alt text that's technically present but nonsensical. These are rare but not evenly distributed — checking a random sample won't reliably surface every one, which is why a bulk review should also include a quick visual scan for outputs that look obviously wrong at a glance, not just a random sample.

A practical walkthrough: designing a spot-check for a large batch

Group the batch by category before sampling, not after. If you generated alt text for 300 WooCommerce products across 8 categories, treat each category as its own mini-batch rather than sampling 15 images at random from the pooled 300 — random sampling from the pool under-samples smaller categories and can miss a category-specific error entirely.
Pull roughly 10–15% from each category, rounding up for small categories (a category of 6 images still needs at least 1–2 checked, not zero).
Read the sampled descriptions against the actual images, checking for the same things a single-image checklist covers: accuracy, appropriate length, no keyword stuffing, no "image of" filler.
If your sample turns up an error, don't just fix that one image. Check whether the same error appears elsewhere in that category — a clustered error usually means checking every image in that specific category, not just widening the random sample.
If the sample comes back clean, apply the batch and log which categories were sampled and when, so a future audit doesn't have to guess what's already been checked.
Re-sample after any regeneration. If you regenerate a subset because the first pass had a category-specific problem, that new subset needs its own spot-check — don't assume a fix worked without checking a sample of the new output too.

Frequently asked questions

What sample size actually catches most bulk alt text errors?

For a batch with distinct visual categories, sampling 10–15% per category (with a minimum of 1–2 images for very small categories) catches most clustered errors, since a systemic problem in a category typically affects most or all of that category's images rather than a random scattered few. For a batch with no natural categories — a single set of visually similar images — a flat random sample of around 15–20% is a reasonable default, though it's less reliable at catching a rare, unevenly distributed error than a categorised sample would be.

Should decorative images be included in the spot-check, or only product and content images?

Include a few, but they don't need the same weight. Decorative images that should have empty alt text (alt="") rather than a description are a distinct failure mode worth checking for separately — an AI generator that isn't told an image is decorative will typically describe it anyway, which is wrong regardless of how accurate the description itself is. Spot-checking a handful of images you know are decorative, specifically to confirm they got empty alt text rather than a generated description, catches this category of error that a normal accuracy-focused sample might miss.

Is spot-checking actually safe, or is full review the only reliable option?

Full review is more thorough in theory, but in practice it's the option that doesn't happen at scale — which makes a disciplined, category-aware sample more reliable than an aspirational full review that gets skipped. Spot-checking isn't a compromise on safety so much as an acknowledgement of how these errors actually cluster: a well-designed sample that specifically targets each visual category catches the kind of systemic mistake that matters most, even though it can still miss a genuinely one-off error buried in an unsampled image.

Designing and tracking a proper category-aware sample by hand adds its own overhead on top of the bulk generation itself. OpptiAI Alt Text generates alt text in bulk across your WordPress media library and flags AI suggestions for review before they save, so you're checking flagged output rather than building a sampling plan from scratch — try the free image SEO audit to see what a scan of your own site turns up first.

Missing SEO Titles Are Quietly Costing You Search Clicks

Benjamin Oats — Tue, 25 Aug 2026 07:11:11 +0000

Missing SEO Titles Are Quietly Costing You Search Clicks

A page without a title tag still ranks. It still gets indexed, still shows up for relevant queries, still has a URL people can click. The part that goes wrong is quieter than a ranking drop: Google writes the blue headline in the search result for you, usually pulling from the H1 or the first readable chunk of content, and what it picks rarely reads like something designed to earn a click. That gap between "still ranks" and "still gets clicked" is where missing titles do their damage, and it's easy to miss because nothing on the page itself looks broken.

Why a missing title costs clicks, not rankings

Ranking and click-through rate are two separate outcomes, and a blank title tag mostly hits the second one. Google's algorithm can still work out what a page is about from its content, headings, and links pointing to it, so a missing title doesn't necessarily tank where the page lands in results. What it does affect is the headline text a searcher actually reads before deciding whether to click.

Search Console's own guidance is direct about this: Google will sometimes rewrite even a well-written title tag if it judges the existing one to be a poor match for a specific query, and it always substitutes something when the tag is blank. Its replacement is generated algorithmically from on-page content, which means it's optimised for describing the page accurately, not for persuading someone scanning ten blue links to pick yours. A deliberately written title can lead with the specific benefit, use language that matches how people actually search, and stand out next to competitors' results — none of which an auto-generated substitute is built to do.

What Google's substitute titles actually look like

A few patterns show up repeatedly on pages with no title tag set:

The H1, verbatim. If your H1 is written for readers already on the page ("Getting Started"), it makes a weak, context-free search result headline for someone who hasn't clicked yet and has no idea what site they're looking at.

A sentence fragment from the first paragraph. Google sometimes pulls the opening line of body content, which can read as an incomplete thought when it's truncated at the search result's character limit — cut mid-sentence rather than at a natural break.

The site name alone, repeated. On archive pages or thin custom-post-type entries with no other clear heading to pull from, some templates fall back to just the site name, which tells a searcher nothing about what the specific page contains.

None of these are wrong, exactly — they're accurate descriptions generated without any attempt at persuasion, because persuasion isn't the algorithm's job.

A practical walkthrough: finding your missing-title pages and estimating the click cost

Crawl the site and export every URL alongside its title tag column, same as any title audit.
Filter for blank cells to build your missing-title list.
Cross-reference with Search Console's Pages report (Performance > Pages, last 90 days) to find which of those URLs actually have impressions — a blank title on a page nobody searches for isn't costing you anything yet.
Check the average CTR for each blank-title page against similar pages on your site that do have a written title, in a comparable position range. A meaningful gap is a rough signal of how much a written title could recover.
Search the exact URL (site:yourdomain.com/page-url) for your highest-impression blank-title pages to see exactly what Google is currently showing as the headline — this is usually the moment the problem becomes obvious.
Write and publish titles for the top tier first, then monitor CTR for those specific URLs over the following few weeks rather than the whole site's average, since sitewide CTR moves too slowly to show the effect of a handful of page-level fixes.

Frequently asked questions

How long does it take to see a CTR improvement after fixing a missing title?

Typically a few weeks, not days. Google needs to re-crawl the page, pick up the new title tag, and start displaying it consistently in results, and CTR itself is measured against enough impressions to be statistically meaningful — a low-traffic page might take a month or more to accumulate enough search appearances to tell whether the fix worked. Checking Search Console's Pages report filtered to that specific URL, comparing the weeks before and after the fix, is more reliable than watching daily numbers.

Does a missing title tag actually hurt rankings, or only the click-through rate?

Primarily click-through rate. Google can generally still determine relevance from page content, internal linking, and other signals even without an explicit title tag, so a blank title isn't typically a direct ranking penalty the way, say, a noindex tag would be. The damage is indirect: a weak or generic auto-generated headline in the search result gets fewer clicks than a deliberately written one at the same position, and click-through rate is itself one of many signals that can influence rankings over time — so the effects aren't entirely unrelated, just not immediate or guaranteed.

Should every page have a manually written title, even low-traffic ones?

Not urgently. For pages with negligible search impressions, a sensible template-level default (via your SEO plugin's title pattern settings) is enough — the return on hand-writing a bespoke title for a page almost nobody searches for is low. Reserve manual, individually crafted titles for pages that already get meaningful impressions or that you specifically want to rank better, and let template defaults handle the long tail.

Finding every blank title on a growing WordPress site by hand means repeating this crawl-and-cross-reference process every time you publish. OpptiAI Titles scans your site for missing and weak titles automatically, drafts replacements for you to review, and runs alongside whichever SEO plugin — Yoast, Rank Math, or AIOSEO — you're already using.

Use a Health Score to Decide Which Titles to Fix First

Benjamin Oats — Tue, 25 Aug 2026 07:11:05 +0000

Use a Health Score to Decide Which Titles to Fix First

Run a full crawl of a mid-sized WordPress site and you'll usually get back a list of fifty, a hundred, sometimes several hundred pages with a title tag problem — missing, duplicated, too long, too short, or just weak. Knowing the list exists doesn't tell you where to start. Without some way to rank the entries, the natural instinct is to start at the top of the spreadsheet and work down, which means you spend the first hour on whatever page happened to sort first, not the page that's actually costing you the most.

A health score fixes that by turning a flat list into a ranked one. Instead of "here are 140 problems," you get "here are the 12 that matter most, and here's roughly why."

What a title health score actually measures

A useful score isn't a single yes/no check — it's a blend of several signals that each catch a different failure mode:

Presence. Is there a title tag and meta description at all, or is the field genuinely blank? This is the most severe issue, since a blank title means Google is writing your search snippet for you.

Length. Titles that are too long get truncated in search results with a trailing ellipsis, cutting off whatever came after the cut point — often the part that would have made someone click. Titles that are too short waste the available space and give Google's algorithm less to match against a query. Meta descriptions have the same problem in reverse proportion: too short and you're leaving persuasive space unused, too long and it gets cut mid-sentence.

Duplication. Two or more pages sharing an identical title tag split whatever ranking signal that title carries, and confuse Google about which page should rank for the phrase both titles contain. A duplicate is worse than a mediocre unique title in most cases.

Traffic and indexing status. This is the signal that turns a static severity score into a prioritised list. A blank title on a page with real organic impressions is a live problem costing you clicks right now. The identical blank title on a noindexed staging page or a post with zero impressions in the last 90 days isn't urgent by comparison, even though the on-page issue looks the same.

That last factor is why a plain crawl export undersells its own usefulness — it tells you what's wrong but not what's worth fixing today.

Why "fix everything eventually" doesn't work in practice

Most site owners who run a full title audit start strong and stop somewhere around item 15. That's not a discipline problem, it's a design problem with treating every issue as equally important. Working a flat list top to bottom means the first hour of effort goes wherever the crawler happened to output first — often alphabetical by URL, which has nothing to do with which pages matter.

A health score reorders the same list by expected impact, so the first hour goes to the dozen pages where fixing the title is most likely to move a needle you can actually see in Search Console a few weeks later. That's a different kind of motivation than working through a long list out of obligation — you can point at a specific page, explain why it's first, and check back on it.

A practical walkthrough: building a rough health score by hand

If you don't have a tool that scores this automatically, you can approximate it with a spreadsheet in about twenty minutes for a small-to-mid site:

Export your crawl with URL, title tag, title length, meta description, and meta description length as columns.
Add an indexing/impressions column by pulling in Search Console's Pages report (Performance > Pages, filtered to the last 90 days) and matching it to your URL list.
Score each row with a simple weighted formula: 3 points for a missing title, 2 for a duplicate, 1 for out-of-range length, then multiply the total by a traffic tier (3x if the page has meaningful impressions, 1x if it doesn't, 0x if it's noindexed).
Sort by the resulting score, descending. The top of the sorted list is your actual priority order, not the crawl's default sort.
Work the top 10–15 first, rewrite, republish, and re-crawl just that batch to confirm the fix landed before moving to the next tier.
Re-run the whole scoring pass monthly or after any bulk content change (migration, rebrand, large import), since new pages and new traffic patterns shift what's actually most urgent.

Frequently asked questions

Isn't a title issue on a low-traffic page still worth fixing eventually?

Yes, just not first. A health score isn't saying low-traffic pages don't matter, it's saying they're not where the next hour of your time returns the most. Once the high-impact tier is cleared, working down through lower-traffic pages is reasonable maintenance — the point of scoring is sequencing effort, not deciding some pages are permanently exempt from getting fixed.

How often should title health actually be re-scored?

Monthly is a reasonable default for a site that publishes regularly, since new pages arrive with their own title gaps and Search Console traffic shifts month to month. Sites with heavier publishing cadences — several posts a week, frequent product launches — benefit from a lighter weekly pass focused only on newly published content, with the full sitewide re-score staying monthly. Any one-off event that touches a lot of URLs at once (a URL structure change, a CMS migration, a rebrand) warrants an immediate re-score regardless of your regular schedule.

Can a health score replace manual judgement on which titles to rewrite?

No, and it isn't meant to. A score is good at surfacing which dozen pages deserve attention this week; it's not good at judging whether a specific rewritten title is actually better, since that depends on matching search intent and brand voice in ways a formula can't fully capture. Treat the score as triage — it tells you where to look — and keep a human reviewing the actual proposed title before it goes live, the same way you'd review any AI-drafted copy.

Sorting a title audit by hand works for a one-off cleanup, but sites that add pages and products regularly need this re-scored on an ongoing basis. OpptiAI Titles runs this health check automatically across your WordPress site, ranks missing and weak titles by likely impact, and drafts suggestions you review before anything goes live — alongside whichever SEO plugin you're already running.

Edit Alt Text Without Opening Every Image

Benjamin Oats — Sat, 22 Aug 2026 07:13:11 +0000

Edit Alt Text Without Opening Every Image

The default way to edit alt text in WordPress is click an image, wait for the attachment modal to open, find the alt text field, type, close the modal, click the next image. That open-and-close cycle is the slowest part of the job — not the writing, the clicking. Skip the modal and edit from a list instead, and the same task takes a fraction of the time.

Here's a short video on what that looks like in practice.

Where the time actually goes

Time a single edit in the default media library and most of it isn't spent writing text. It's the modal loading, the scroll to find the alt text field among the other metadata, the click into the field, and then the close-and-reopen for the next image. The actual typing is a few seconds. The surrounding clicks and waits are what add up across a real backlog.

Multiply that overhead by a couple hundred images and the modal cycle alone can account for a meaningful chunk of the session — time spent navigating the interface, not doing the work the interface is supposed to support.

What editing from a list removes

A list view with an inline alt text field next to each thumbnail cuts the modal out of the loop entirely. You see the image and the current alt text status in the same row, click into the field, type, and the next row is already visible — no navigating away and back.

The difference isn't the typing speed, it's the number of actions per image. Modal-based editing is open, locate field, type, close: four steps minimum. Inline editing from a list is click field, type: two. Removing two steps per image, multiplied across a few hundred images, is where the real time saving comes from.

Working a list without the modal

Pull up the list view, not the grid — a list format with a visible alt text column makes the current status of every image scannable at a glance, which the grid view doesn't give you without opening each one.
Sort or filter to what needs work. Combine this with a missing-or-weak filter so every row on screen is relevant, not just faster to reach.
Edit directly in the row. Click into the alt text field for that row, type or accept a suggestion, and move to the next without a page reload or modal transition.
Save as you go, or in a batch, depending on what your setup supports — either works, as long as you're not reopening a modal per image to do it.
Spot-check a few afterwards by viewing the actual page they're used on, since list-view editing is fast enough that it's worth a quick sanity pass once you're done.

Why this matters more than it sounds like

Saving a few clicks per image sounds minor until it's the difference between a task that gets done and one that gets postponed. A backlog of 300 images at four clicks and a modal load each feels like an afternoon project — the kind of thing that gets pushed to "when I have time," which in practice means never. The same 300 images at two clicks each, with no modal, fits into a coffee-break session, and tasks that fit into a coffee break actually get done.

The interface friction isn't a minor annoyance. It's often the actual reason a known backlog stays unfixed for months.

Frequently asked questions

Does WordPress support inline alt text editing by default?

Not really. The core media library's list view shows filenames and a few columns, but editing alt text still routes through the attachment details modal by default. Inline, in-row editing of alt text typically requires a plugin that adds an editable column to the media list.

Is inline editing less careful than reviewing each image in the modal?

Not if you're still looking at the image and the text together, which a well-built list view shows side by side anyway. The modal doesn't make you more careful — it just adds navigation steps between images. Speed and carefulness aren't the same axis; you can review just as closely in a list row as in a modal, in less time.

Is this worth setting up for a site with only a handful of images missing alt text?

Probably not on its own — if you're fixing five images, the modal overhead barely registers. It starts to matter once the backlog is in the dozens or hundreds, or once alt text editing becomes a recurring task rather than a one-off cleanup, since that's when the per-image overhead compounds into real time.

Try OpptiAI Alt Text to edit alt text directly from a list across your WordPress media library, or run a free image SEO audit to see how many images are waiting on you.

The Four-Point Checklist for Reviewing AI Alt Text

Benjamin Oats — Sat, 22 Aug 2026 07:12:28 +0000

The Four-Point Checklist for Reviewing AI Alt Text

AI just wrote alt text for your image, and it might be wrong — not obviously wrong, just wrong enough that hitting save turns a missing field into a confident mistake. The fix isn't reading every suggestion end to end and hoping you spot the problem. It's checking for a small number of specific failure modes that cover most of what actually goes wrong.

Here's a short video walking through the checklist and fixing bad suggestions live in WordPress.

Filled is not the same as finished

A field with text in it looks done. That's the trap: an alt attribute containing any string passes an automated "has alt text" check, whether that string is a genuinely useful description or three keywords jammed together with no verb. AI makes this worse, not better, because a fluent-sounding sentence clears the bar of "looks like alt text" even when it's describing the wrong object entirely.

The checklist below exists because reading a suggestion and generally agreeing with it isn't the same as checking it against these specific ways it fails.

The three failure modes to watch for

Almost every bad AI alt text suggestion falls into one of three patterns:

Weak. Technically accurate, uselessly vague — "a person in a room," "a product on a white background." It passes a glance and tells a screen reader user almost nothing about what's actually in the image.

Wrong. The model names the wrong object, the wrong colour, or the wrong count. This is the one that's easiest to miss on a fast read, because wrong text is often just as fluent as correct text.

Keyword-stuffed. A string of nouns instead of a description — "shoes sneakers footwear trainers running shoes" — written to look SEO-friendly rather than to describe the image. It reads as spam to both a screen reader and a search engine, and it fails accessibility and SEO at the same time.

The four-point review checklist

Run these four checks on every AI suggestion before you save it:

Is it specific, not generic? Catches weak alt text. If the description would still be accurate for a dozen other images in your library, it's too vague — it should name the specific thing, not the category.
Does it match what's actually in the image? Catches wrong alt text. Look at the photo first, then read the suggestion, and check the object, colour, and count against what you see — not what you'd expect.
Is it a sentence, or a list of keywords? Catches keyword stuffing. Alt text should read the way you'd describe the image out loud to someone who can't see it, not the way you'd write a product tag list.
If the image is decorative, is the field empty? Catches the fourth failure mode: over-describing images that need silence instead. A purely decorative divider or background flourish should get an empty alt attribute so a screen reader skips it, not a manufactured description of a shape nobody needs read aloud.

Fixing what the checklist catches

Don't discard a flagged suggestion and start over — edit the part that's wrong. A weak suggestion usually needs one added detail, not a full rewrite. A wrong suggestion needs the incorrect noun or colour swapped for the correct one. A stuffed suggestion needs converting into an actual sentence, which is often faster than it sounds because the right words are already there, just not in the right order. And a decorative image wrongly given a description just needs the field cleared.

This keeps review fast. You're rarely writing from a blank field — you're making a small, specific correction to something that's mostly there.

Building the checklist into a batch habit

Checking one suggestion carefully is easy. The checklist earns its keep on a batch of thirty or forty, where the temptation is to skim the ones that look fine on a fast read. A few habits keep the checks real instead of theoretical:

Go in the same order every time — specific, correct, not stuffed, decorative-empty — so it becomes automatic rather than something you have to consciously reconstruct for each image. Slow down on images that feel "obviously fine," since those are exactly the ones most likely to get waved through without a real check. And if you're reviewing more than about 30 in a row, take a short break; checklist accuracy drops on a long unbroken run the same way any careful task does.

Frequently asked questions

What's the most common AI alt text mistake this checklist catches?

Weak, generic descriptions are the most frequent issue — text that's technically accurate but too vague to be useful, like "a product on a table" for an image that needs the specific product named. It's also the easiest to miss on a quick read, because a vague sentence is still a grammatically correct sentence.

Should decorative images have any alt text at all?

No — a purely decorative image (a background flourish, a spacer graphic, a repeated divider) should have an empty alt attribute (alt=""), not a description. An empty alt tells a screen reader to skip the image entirely, which is correct when the image carries no information. Writing a description for a decorative image adds noise a screen reader user has to sit through for nothing.

How long should reviewing one AI alt text suggestion actually take?

A few seconds once the checklist is a habit — look at the image, read the suggestion, run the four checks, edit if needed, save. It's slower than blindly accepting, but far faster than writing a description from a blank field, which is the actual time comparison that matters.

Try OpptiAI Alt Text to draft and review alt text across your WordPress media library, or run a free image SEO audit to see where your current alt text needs a second look.

Filter Your Media Library to Missing Alt Text First

Benjamin Oats — Sat, 22 Aug 2026 07:12:23 +0000

Filter Your Media Library to Missing Alt Text First

Most WordPress media libraries mix everything together — images with good alt text, images with none, images that don't need any at all. Scrolling through all of it to find the gaps means you spend most of your session looking at images that are already fine. Filter to what's actually missing first, and the whole task shrinks to the list that matters.

Here's a short video on why filtering first changes how the work feels.

Why scrolling the whole library wastes the session

The default WordPress media grid shows everything in upload order, with no distinction between an image that has solid alt text and one that's been blank since 2022. If you're hunting for gaps by eye, you're opening images at random, checking the alt field, closing it, and moving to the next — and on a site with a few thousand images, the ones that need attention are a small fraction of what you're looking at.

That ratio is the actual problem. Say 200 of 3,000 images are missing alt text. Scrolling in upload order means roughly 93% of what you see is already fine. You're not doing alt text work for most of that time — you're doing search work, and search work with no filter is slow by design.

What filtering first changes

Filtering flips the task from "look at everything and judge each one" to "start with a list that's already all relevant." Instead of opening images to check their status, the list itself only contains images with missing or empty alt text — every row on the screen is something that needs fixing, so there's no wasted attention.

This matters more as a site grows. A filtered list of 200 stays a fixed, finishable task regardless of how large the surrounding library gets. An unfiltered scroll through the whole library gets slower every time more images get uploaded, because the haystack grows even though the needles don't.

Building the filtered list

Pull a full count first. Before filtering anything, get a total: how many images across the site have missing or empty alt text. This gives you a number to work against instead of an open-ended scroll.
Filter to missing only. Exclude anything with existing alt text, however short or generic — the goal at this stage is finding true gaps, not judging quality yet.
Sort by where it matters most. If you can, put images used on published pages and products above ones sitting unused in the library. A blank alt field on your homepage hero matters more than one on an unused draft attachment.
Work the list top to bottom. Because every entry is relevant, you can move through it without re-checking status — write or generate the description, save, next.
Re-run the filter after a batch. Once you've cleared a chunk, filter again to confirm the count actually dropped. This catches anything that was accidentally skipped.

Filtering also catches what a full scroll misses

A raw scroll biases toward recently uploaded images, because that's what's visible first in most grid views without extra clicking. Older images — ones from a redesign three years ago, or a bulk import that never got proper alt text — sink to the bottom and stay there indefinitely, because nobody scrolls that far during a normal session.

A filter doesn't care about upload date. It surfaces every image missing alt text regardless of when it landed in the library, which is usually where the oldest and most overlooked gaps are hiding.

Keeping the filtered list at zero

Filtering once clears a backlog. Keeping it clear means checking the filter regularly rather than only when the problem feels big again:

Run the missing-alt-text filter on a schedule — weekly is reasonable for a site that publishes often — and treat a non-zero count as the trigger to work the list, not a stat to note and ignore. New uploads without alt text will always appear; the filter is what stops them from quietly accumulating into another few-hundred-image backlog.

Frequently asked questions

Does WordPress have a built-in way to filter for missing alt text?

Not out of the box. The default media library lets you filter by file type, upload date, and a few other attributes, but "alt text is empty" isn't one of the native filter options. Getting that view typically requires a plugin that scans the media library and surfaces missing or empty alt text as a filterable list.

Should I filter by missing alt text or by image quality of existing alt text?

Start with missing — it's a clear yes/no and clears the biggest gap fastest. Once that list is at zero, a second pass filtering for existing-but-weak alt text (too short, generic, or keyword-stuffed) catches the next tier of problems. Doing both at once tends to slow down the first, more urgent pass.

How do I know if a filtered list is actually complete, or missing some images?

Cross-check the count against a separate total, if your plugin or database gives you one — for example, total images on the site versus images with any alt text at all, versus images the filter flags as missing. If the maths doesn't add up, some images (often ones embedded via a page builder rather than the standard media library) may not be getting scanned.

Try OpptiAI Alt Text to filter your WordPress media library down to what's actually missing alt text, or run a free image SEO audit to get a starting count for your site.

How to Find Duplicate Title Tags on a WordPress Site

Benjamin Oats — Thu, 20 Aug 2026 07:22:11 +0000

How to Find Duplicate Title Tags on a WordPress Site

Two pages on the same WordPress site sharing a title tag is more common than it should be, and it's rarely deliberate. It splits ranking signal between the pages instead of strengthening either one — Google has to guess which page you actually want to rank for that query, and a shared title tag gives it no reason to prefer one over the other.

Duplicate titles creep in from places that don't feel like a decision at all: a theme's default template falling back to the site name for every archive page, a plugin generating the same fallback string for every empty field, or a page cloned as a starting point and never renamed. None of it looks wrong in the WordPress editor, because the title field is usually fine — it's the rendered <title> tag that ends up identical.

Where duplicates actually come from

Archive and taxonomy pages are the most common source. If your theme doesn't set a distinct title template for categories, tags, and author archives, several of them can render the exact same fallback title — often just the site name, or "Blog" repeated across every one.

Paginated pages are next. /blog/, /blog/page/2/, /blog/page/3/ frequently carry the identical title with no page-number distinction, because most themes don't append "– Page 2" unless a plugin specifically handles it.

Cloned pages and templates. A page duplicated as a starting point for a new landing page keeps the original's title until someone remembers to change it — easy to miss on a page that isn't linked from the main menu yet.

Plugin-generated pages. WooCommerce shop, cart, and checkout pages, or search results pages, sometimes fall back to a generic title from the plugin itself rather than something the theme or an SEO plugin sets explicitly.

Multisite or staging remnants. Content migrated from a staging subdomain or duplicated for an A/B test can leave two live URLs with identical title tags long after the test ended.

Why "just write different titles" undersells the fix

Finding one duplicate is easy — you'll trip over it eventually. Finding all of them means checking every published URL, not just the ones you remember creating. A site with a few hundred posts and a handful of taxonomies can easily have dozens of title collisions hiding in archives and pagination that nobody looks at directly, because nobody visits /category/uncategorised/page/4/ on purpose.

Auditing a site for duplicate title tags

Export a full URL list — your XML sitemap is the fastest source; most SEO plugins generate one at /sitemap.xml or /sitemap_index.xml covering posts, pages, and taxonomy archives.
Pull the rendered <title> for each URL, not the WordPress "Title" field in the editor — SEO plugins and theme templates can override what actually renders, so the field and the output can differ.
Sort and group by exact title text. Any group with more than one URL is a duplicate — the interesting cases are groups of three or more, which usually point to a template-level cause rather than a one-off.
Separate genuine near-duplicates from template artefacts. Two similar product names sharing a template is a different fix (write both titles properly) from twenty archive pages sharing a fallback (fix the template default once).
Prioritise by traffic or impressions, not alphabetically — a duplicate on a page that gets zero search traffic matters far less than one on a page competing for real queries. Google Search Console's Performance report, filtered by page, tells you which duplicates are actually costing you something.
Fix the template-level cases first. One theme or plugin setting fixed once resolves every archive page it affects, which is a better return than rewriting individual page titles one at a time.

Duplicate titles on WooCommerce sites specifically

WooCommerce stores get their own variant of this problem, on top of the general WordPress causes above. Product variations are the biggest one: a T-shirt in five colours, imported as five separate simple products rather than one variable product, often keeps the same base title across every colour — "Cotton T-Shirt" repeated five times with nothing distinguishing red from blue in the title tag itself, even though the description or attributes differ.

Bulk CSV imports compound this. A product feed imported from a supplier or a legacy platform frequently carries the supplier's generic naming — "Product 4471" or a bare SKU — straight into the title field, and if several rows share a template default, you get identical titles across dozens of SKUs in one import pass rather than one at a time.

Category and shop-page templates cause the same fallback issue WordPress archives do, but WooCommerce adds its own set: the shop page, and any custom product category landing pages, can inherit a generic "Shop" or site-name title if the templates were never customised when the store was set up.

Using Search Console to confirm the impact, not just find the list

A sitemap audit tells you where duplicates exist; Search Console tells you whether they're actually costing you anything. Open the Performance report, add a filter for the specific page, and check whether Google is showing that URL for queries you'd expect a distinct page to rank for. If a duplicate-titled page has meaningful impressions and a competing page for the same topic has none, that's the pair worth fixing first — you can see the ranking signal being split in the data rather than guessing at it.

It's also worth checking the "Pages" report under Indexing for any pages Google has marked as a duplicate without a user-selected canonical. That report is a shortlist Google has effectively already generated for you of pages it considers indistinguishable from another — often a faster starting point than sorting a full sitemap export by hand.

What a good fix looks like

A distinct, specific title per URL — not just different from its duplicate, but actually descriptive of that page's content. "Blog – Page 2" is a legitimate fix for pagination; two completely different product pages both titled with the site name need real, specific titles reflecting what's actually on each one. The goal isn't uniqueness for its own sake, it's giving Google (and the person scanning search results) a genuine reason to click the right page for their query.

Frequently asked questions

Does Google penalise a WordPress site for duplicate title tags?

Not as a manual penalty, but the practical effect is similar. When two pages share a title, Google has to pick one to show for a given query and may treat the other as a near-duplicate, sometimes filtering it from results entirely or ranking it far lower. You're not fined for it — you're just competing against your own page for the same ranking position, which nobody wins.

Why do WordPress category and tag pages so often share the same title?

Most themes generate archive titles from a template that falls back to something generic — usually the site name, or a bare label like "Category" — when no custom title has been explicitly set for that taxonomy term. Since almost nobody edits individual category or tag titles by hand, every archive using the same fallback template ends up with an identical rendered title, even though each one lists genuinely different content.

How many duplicate title tags is normal on a WordPress site?

There's no fixed number, but a healthy site should have close to zero duplicates on pages that receive any organic traffic. A handful of duplicates on obscure paginated archives with no search visibility isn't worth chasing immediately; duplicates on your main product, service, or landing pages are worth fixing straight away, since those are the URLs actually competing for rankings against each other.

Running a full title tag audit by hand across every archive, paginated page, and cloned template is the kind of task that's easy to start and hard to finish thoroughly. OpptiAI Titles scans a WordPress site for missing and duplicate titles and meta descriptions, then drafts specific replacements you review before applying — built to run alongside Yoast, Rank Math, or AIOSEO rather than replace them.

Alt Text Gaps in Multilingual WooCommerce Stores

Benjamin Oats — Thu, 20 Aug 2026 07:22:08 +0000

Alt Text Gaps in Multilingual WooCommerce Stores

Run a WooCommerce store in more than one language and there's a good chance half your product images are described in the wrong language, or not described at all. WPML and Polylang duplicate the product, the price, the description — but the featured image and gallery images usually get duplicated as references, not re-translated. The English alt text rides along into the French, German, or Spanish version of the page untouched.

Most site owners never notice, because the images themselves still display correctly. Nothing looks broken in the browser. The gap only shows up when you check what a screen reader announces on the translated page, or when you look at how Google Images ranks the non-English version against the original.

Why translation plugins skip alt text by default

WPML and Polylang were built to translate strings — post titles, body content, product descriptions, taxonomy labels. Media attachments sit slightly outside that model.

WPML's default behaviour: when you duplicate a product into a new language, WPML by default reuses the same featured image and gallery attachment IDs across all translations, unless you've explicitly enabled "Custom Fields Translation" for image alt text or turned on media translation in WPML's Media settings. Even then, translating the attachment alt text field is a separate, easy-to-miss step from translating the product itself. It's not part of the main product translation editor most people use day to day.

Polylang's default behaviour: Polylang treats each media item as its own translatable object, which sounds better in theory. In practice, most stores never create a translated copy of the attachment — they just attach the same image ID to every language version of the product, because duplicating media files serves no visual purpose. The alt text field on that shared attachment can only hold one value at a time, so whichever language it was written in last is what every version of the page gets.

Either way, the practical result is the same: one alt text string, several languages of product page, and no warning that anything's missing.

Why it actually matters here

For a single-language store, alt text is mostly about accessibility and image search. For a multilingual store, there's a third factor: Google indexes translated pages separately, using hreflang to understand which version serves which market. If the French version of a product page has English alt text, that's a language-mismatch signal on exactly the element Google Images uses to understand what the image shows — on the one page where matching content to locale matters most.

For a screen reader user on the French page, hearing "blue ceramic mug" announced when everything else on the page reads in French is a jarring, obviously untranslated experience — worse than no alt text at all in some assistive tech, because it interrupts the reading language mid-sentence.

Finding the gap on your own store

Pick your two most different languages — ideally ones using different scripts or clearly different vocabulary, so a mismatch is unmissable (English/German is fine; English/English-US is not).
Open the same product in both languages side by side, using your translation plugin's language switcher, not two separate tabs you navigated to manually — you want to confirm it's genuinely the translated version.
Inspect the image element (right-click → Inspect, or view page source and search for the product image filename) and read the alt attribute on each language version.
Note whether it's identical, blank, or genuinely translated. Identical text across languages is the most common failure. Blank alt text is the second most common — some translation setups strip the field entirely on the duplicated attachment rather than copying it.
Check the gallery images, not just the featured image. Featured images get more attention during setup; gallery images almost always inherit whatever the first-created language version had.
Repeat across a sample of 5–10 products, not just one — if the pattern holds, it's a sitewide setup issue rather than an isolated oversight, and worth fixing at the attachment-translation-setting level, not product by product.

If most of your alt text turns out identical across languages, the fix isn't rewriting it per product by hand — that doesn't scale past a handful of SKUs. It's re-running a proper alt text pass on each language version separately, treating each translated product's images as needing their own description rather than inheriting one written for a different market.

What "fixed" looks like

The end state isn't just "every image has alt text" — it's every image has alt text in the language of the page it's on. A German product page with a German alt text string, a French one with French. That's a bigger job than a single-language store's alt text backlog, because it multiplies by however many languages you support, but it's the same underlying workflow repeated per locale: scan, review the suggestion, save.

OpptiAI Alt Text scans your media library and drafts suggestions you review before saving — running it once per language version, rather than once for the store as a whole, catches exactly this kind of gap because it's working from what's actually on each translated page rather than assuming one description fits every locale.

Frequently asked questions

Does WPML translate image alt text automatically?

Not by default. WPML translates post content, titles, and most taxonomy fields automatically when you duplicate a product into a new language, but the attachment's alt text field is treated separately. You need to enable custom field translation for it specifically, or use WPML's Media Translation add-on, and even then someone still has to write or review the translated string — WPML doesn't generate translated alt text on its own, it just gives you a place to put it.

Can I use the same alt text across all language versions of a product?

You can, but it undermines the reason you're running a multilingual store in the first place. Alt text read out by a screen reader or indexed by Google should match the language of the surrounding page. Identical alt text across languages either forces non-English readers to hear English text, or forces you to write English-only descriptions that don't reflect the market you're translating for. It's a shortcut that costs you both the accessibility and the SEO benefit in every language except the original.

How do I check which WooCommerce products have mismatched alt text across languages without checking every product by hand?

There's no built-in WooCommerce report for this specifically — you're comparing the same attachment's alt text field against the language of the page rendering it, which most audit tools don't cross-reference. The manual sampling method above (checking 5–10 products across your two most distinct languages) is usually enough to confirm whether it's a sitewide pattern. Once confirmed, the fix is a per-language content pass rather than a one-off audit script, since each language genuinely needs its own reviewed alt text rather than a detection-only report.

Multilingual alt text gaps are easy to miss because nothing about the page looks broken — every image still loads, every price still displays. OpptiAI Alt Text scans your media library and drafts descriptions you review before saving, which makes a per-language pass practical instead of a manual slog. If you want a quick read on where your store currently stands, the free image SEO audit checks a URL in under a minute.

A Four-Step Workflow for Full-Site Alt Text Cleanup

Benjamin Oats — Wed, 19 Aug 2026 07:09:23 +0000

A Four-Step Workflow for Full-Site Alt Text Cleanup

A full-site alt text cleanup isn't one task, it's four, and doing them in the wrong order — or skipping one — is why most cleanups either stall or ship mistakes. Scan first, prioritise what you scanned, generate descriptions for what you prioritised, then review before anything saves. Cut the review step and you haven't finished the job, you've just bulk-saved whatever the generator handed you.

Here's a short video walking through why the order matters and where each step earns its place.

Why the order matters more than the tools

Most alt text cleanups fail for a process reason, not a tooling reason. Someone opens the media library, starts generating descriptions for whatever image happens to be on screen, and either burns hours on low-value images or trusts a batch of AI output without checking it. Both failure modes trace back to skipping a step in the sequence.

Scan, prioritise, generate, review isn't an arbitrary checklist — each step depends on the one before it and protects against a specific failure:

Scan exists because you can't prioritise what you haven't counted. Without a full inventory, "prioritising" is really just working on whatever's visible, which is usually recent uploads, not the images that matter most.
Prioritise exists because not every missing alt text is equally urgent. A product image on your highest-traffic page matters more than a decorative background image buried in an old post.
Generate exists because writing hundreds of descriptions by hand is where most people give up. This is the step AI genuinely helps with — drafting a first pass fast.
Review exists because generated text is a draft, not a finished product. Skip it and you've traded "no alt text" for "wrong alt text," which is arguably worse since it now looks done.

Step 1: Scan the whole media library

Start from your media library, not your published pages. Posts and pages only show you the images that made it into visible content — your media library holds everything, including images attached to deleted drafts, old product galleries, and page-builder elements that don't show up in a normal content read-through.

A scan should split results into at least three buckets: images with no alt text, images with weak alt text (filenames, single generic words, keyword-stuffed text), and images that are already fine. That split is what makes step two possible — you can't prioritise a pile you haven't sorted.

Step 2: Prioritise by where the image actually lives

Not every gap deserves the same attention first. Work through the scan results in roughly this order:

High-traffic pages first. Images on your homepage, top landing pages, or best-selling products carry more SEO and accessibility weight than images on a post nobody visits.
Meaningful images before decorative ones. An image that conveys information — a product photo, a diagram, a screenshot — needs a real description. A purely decorative image often needs an empty alt attribute, not a written one, so screen readers skip it.
Clusters over stragglers. If missing alt text concentrates in one source — a WooCommerce import, a theme's demo content — fixing that cluster in one pass clears more of the backlog than picking off individual images at random.
Weak alt text after missing alt text. An empty field is a clearer signal of neglect than a mediocre one; clear the total blanks first, then come back for the keyword-stuffed or filename-style entries.

Step 3: Generate descriptions in batches

Once you know what to fix and in what order, generating drafts is the fast part. AI can look at an image and produce a plausible description far quicker than typing two hundred of them by hand — that's the entire point of using it here. But "fast" is exactly why this step can't be the last one. A generator has no idea what your page is actually about, whether an image is decorative, or whether your brand has house style for how products get described. It's producing a draft, and drafts need a human pass.

Step 4: Review before anything saves

This is the step that turns a batch of guesses into finished alt text, and it's the one that gets skipped when people are in a hurry to clear a big number. For each generated description, check three things: is the image meaningful or decorative (decorative should be empty, not filled), does the description actually match what's in the frame, and is it concise rather than padded with keywords. Edit what's wrong, clear what should be empty, and only then save back to WordPress.

Skipping review doesn't save you time overall — it just moves the cost downstream. Wrong or oddly generic alt text sitting live on your site is arguably a worse state than an empty field, because an empty field is an honest signal you haven't gotten to it yet, while wrong text looks finished and often goes unnoticed for months.

Running the workflow end to end

The OpptiAI Alt Text plugin is built around these four steps in order: it scans your full media library, groups results so you can prioritise by page and status, generates draft descriptions in batches, and holds everything in a review queue before anything writes back to WordPress. Nothing saves automatically — you see each draft next to its image and decide before it goes live. If you want a quick read on where your site currently stands, the free image SEO audit checks what's rendering on your live pages as a starting scan.

Frequently asked questions

What order should I fix alt text in on a large WordPress site?

Scan your full media library first to get an accurate count and split of missing versus weak alt text. Then prioritise by where images live — high-traffic pages and meaningful (non-decorative) images first, followed by clusters from a specific source like a product import. Generate draft descriptions for the prioritised batch, then review every draft before saving. Doing these out of order — generating before prioritising, or saving before reviewing — is what causes most cleanups to either stall or ship errors.

Can I skip the review step if I'm confident in the AI-generated alt text?

No, not for a full-site cleanup. AI-generated descriptions are frequently accurate but occasionally wrong in ways that matter: misreading what an image shows, describing a decorative image as if it were meaningful, or missing context only a human editing the page would know. Reviewing a batch of drafts takes a fraction of the time it took to generate them, and it's the difference between "this alt text is correct" and "this alt text was probably fine."

How do I decide if an image needs written alt text or an empty alt attribute?

Ask whether removing the image would lose any information a reader needs. If yes — a product photo, a chart, a screenshot with text in it — it needs a real, specific description. If no — a spacer, a repeated background pattern, a purely stylistic flourish — it should get an empty alt attribute (alt="") so screen readers skip past it instead of reading out noise. This decision belongs in the prioritise and review steps, not the generate step, since a generator will usually try to describe everything whether or not a description is useful.

A Review-Edit-Save Workflow for AI Alt Text

Benjamin Oats — Mon, 17 Aug 2026 14:06:40 +0000

A Review-Edit-Save Workflow for AI Alt Text

AI can generate an alt text draft in the time it takes to click a button. That speed is the whole appeal, and it's also exactly why a loose process turns into a bad habit fast — when drafting is instant, saving without reviewing is instant too. A simple three-step workflow, review, edit, save, keeps the speed while putting a real check between the AI's output and your live site.

Here's a short video on what that workflow looks like in practice.

Step one: review, in two specific checks

"Review" is too vague to be a real step on its own — it needs to mean something specific, or it turns into a quick glance that catches nothing. Two checks make the review step concrete:

Meaningful or decorative? Before judging whether a description is accurate, decide whether the image needs a description at all. A product photo, a chart, a screenshot showing something specific — those are meaningful and need real alt text. A background texture, a spacer graphic, a purely visual divider — those are decorative and should get an empty alt="" rather than a forced description. AI tools sometimes draft text for decorative images anyway, describing a texture or pattern nobody needs read aloud. Catching this in review is a one-second judgement call: does this image carry information, or is it just visual polish?

Does it match the frame? For meaningful images, check the draft against what's actually in the photo — not a general sense of "does this sound plausible" but a direct comparison. Right colour, right count, right object. This is where AI drafts most often go subtly wrong: fluent, confident, and slightly off from what's actually pictured.

Step two: edit, don't discard

If the review step flags a problem, the instinct is often to delete the AI's draft and start over. That's usually the wrong move — most AI drafts are mostly right, with one specific thing wrong: a colour, a count, a missing product name. Editing that one detail is faster than rewriting, and it keeps the workflow quick enough that you'll actually stick with it across a large batch of images.

Editing also covers length. AI-drafted alt text tends to run either too short — a generic phrase that technically describes the image but tells a screen reader user nothing useful — or too long, narrating details that don't matter. The edit step is where you trim a rambling draft down to what's actually needed: specific enough to be useful, short enough that a screen reader doesn't spend ten seconds reading a caption for one photo.

A rough length target helps here — most good alt text lands under about 125 characters. If an edited draft is running well past that, look for what's not pulling weight, usually adjectives or scene-setting detail that doesn't change what the reader understands about the image.

Step three: save, with the count in view

The save step sounds trivial, but it's where a batch workflow either holds together or falls apart. Saving one image at a time after each review breaks the rhythm of reviewing a batch. Saving a full reviewed batch at once keeps the process moving — but only if every image in that batch actually went through steps one and two first.

The failure mode to watch for is saving out of habit once you've reviewed several images in a row and they've all been fine. That streak is exactly when the next AI draft is statistically more likely to have a real error, because you've stopped applying the same attention you did to the first few.

Putting the three steps together on a real batch

Here's what review-edit-save looks like across a batch of ten AI-drafted descriptions:

Generate drafts for all ten images at once.
Go through each one, deciding meaningful or decorative first, then checking the meaningful ones against their photo.
Flag the ones needing an edit — say, three out of ten have a wrong detail or run too long.
Edit those three, leaving the other seven as drafted.
Save the batch of ten together.

The three flagged images are where the actual work happens. The other seven pass through review quickly precisely because the check is specific enough to confirm "this is right" fast, rather than requiring a full rewrite-from-scratch comparison every time.

Why skipping straight to save undoes the whole benefit

The appeal of AI-drafted alt text is speed without sacrificing quality. Skip the review and edit steps, and you keep the speed but lose the quality control — which means every error the AI makes ships straight to your live site and stays there until someone happens to notice. The review-edit-save workflow isn't extra work bolted onto AI drafting; it's the part that makes AI drafting safe to use at scale in the first place.

Frequently asked questions

How long should reviewing one AI-drafted alt text take?

For a meaningful image with an accurate draft, a couple of seconds — glance at the photo, glance at the text, confirm it matches. Images that need an edit take longer, but only because you're fixing a specific issue, not re-evaluating from scratch. Across a batch, most images should be quick "yes, that's right" checks, with a minority needing real attention.

How do I decide if an image is decorative or meaningful?

Ask whether removing the image would remove information a reader needs, or only remove visual decoration. A photo of a product, a screenshot with text in it, a chart — removing these loses information, so they're meaningful and need real alt text. A background pattern, a divider line, a purely aesthetic border image — removing these changes nothing about what the page communicates, so they're decorative and should get alt="".

Should I ever skip the review step for AI-drafted alt text?

No — but the review step doesn't have to be slow. The goal is a fast, specific check (meaningful or decorative, does it match the frame) rather than a lengthy audit. Skipping it entirely removes the only point in the workflow where an AI's confident but wrong description gets caught before it reaches your live site.

Try OpptiAI Alt Text to draft, review, and save alt text across your WordPress media library in one workflow, or run a free image SEO audit to see where your current alt text needs attention.

How to Clear a 300-Image Alt Text Backlog

Benjamin Oats — Mon, 17 Aug 2026 14:05:56 +0000

How to Clear a 300-Image Alt Text Backlog

300 missing alt tags sounds like a number you can chip away at over a few evenings. It usually isn't. Sites accumulate missing alt text quietly — a product launch here, a blog migration there — until the total is large enough that "I'll get to it" stops being a realistic plan. Clearing a backlog that size needs a different approach from fixing the odd image as you notice it.

Here's a short video on taking a count from 300 missing alt tags down to zero.

Why 300 missing alt tags accumulates without anyone deciding it should

Nobody sits down and decides to skip alt text on 300 images. It happens in small, individually reasonable moments: a product import that pulls in images without descriptions, a theme change that swaps out featured images, a content migration that carries text over but drops metadata, a busy week where a dozen blog posts go up without anyone circling back to the images.

Each of those moments adds five, ten, twenty images to the pile. None of them feel urgent on their own. The total only becomes visible when someone actually counts it — and by then it's large enough to feel like a project rather than a task.

Step one: get the real number, not an estimate

You can't plan a fix for a backlog you haven't measured. Guessing "probably a hundred or so" leads to underestimating the time needed and abandoning the effort partway through when the real number turns out to be three times that.

A full site scan — checking every image across posts, pages, and product listings for a missing or empty alt attribute — gives you the actual count. This matters for two reasons: it tells you honestly how much work is ahead, and it gives you a baseline number to watch drop, which is motivating in a way that "I fixed some images today" isn't.

Step two: sort by where the images actually matter

Not all 300 images carry equal weight. Before fixing anything, it helps to separate them into rough priority groups:

Product and service images — these directly affect SEO for pages that drive revenue and are usually worth fixing first.

Blog post hero and inline images — these matter for content SEO and accessibility but are typically lower-traffic individually than product pages.

Decorative images — background textures, dividers, spacer graphics. These don't need descriptive alt text at all; an empty alt="" is correct. Sorting these out of the 300 early can shrink the real backlog meaningfully, since decorative images often get miscounted as "missing" when they're not actually a problem.

This sorting step alone can turn a 300-image backlog into a 220-image one before you've written a single description, simply by correctly excluding images that were never supposed to have alt text.

Step three: fix in batches, checking in on the count

With the list sorted, work through it in batches rather than end to end in one sitting:

Take the highest-priority group first — usually product images.
Generate or write descriptions for that whole group in one pass.
Review each one against its image before saving.
Check the updated total. Watching 300 drop to 260, then 200, then 140 makes the scale of the task feel manageable in a way the original number didn't.
Move to the next group and repeat.

Breaking the work into checkpoints tied to a visible, shrinking number keeps the project from feeling open-ended. An open-ended task is easy to abandon; a countdown is easier to finish.

Preventing the backlog from rebuilding

Getting to zero once doesn't keep you at zero. The same causes that built up 300 missing images the first time — imports, migrations, busy publishing weeks — will do it again unless something catches new gaps as they appear.

A recurring scan, even a quick monthly one, catches new missing alt text while the count is still in the tens rather than the hundreds. Fixing 15 new images a month is a five-minute task. Fixing 300 that accumulated over two years is a project. The difference is entirely about how often you check, not how good you are at writing alt text.

Frequently asked questions

How long does it actually take to clear 300 missing alt tags?

Writing each one from scratch manually, at roughly a minute per image including opening and saving, that's around five hours of continuous work — rarely realistic in one sitting. Sorting out decorative images first (which don't need real descriptions) and working through the rest in reviewed batches typically cuts that closer to one to two hours of focused time, spread across a couple of sessions.

Do decorative images count toward a "missing alt text" total?

They shouldn't, but many audit tools count them anyway because they can't tell a decorative background graphic from a product photo. A decorative image with an empty alt="" attribute is correctly formatted, not broken — sorting these out of your backlog before fixing anything is often the fastest way to shrink an inflated count.

What's the best order to fix a large alt text backlog in?

Prioritise by impact, not by chronology. Product and service images that appear on revenue-driving pages are usually worth fixing before older blog post images, since they carry more SEO weight and are more likely to appear in image search results tied to purchase intent. Decorative images should be excluded from the "to fix" list entirely rather than worked through last.

Try OpptiAI Alt Text to scan your whole WordPress site and clear a large alt text backlog in batches, or run a free image SEO audit to see your current missing alt text count.

Stop Fixing Alt Text One Image at a Time

Benjamin Oats — Mon, 17 Aug 2026 14:05:52 +0000

Stop Fixing Alt Text One Image at a Time

Open the media library, click the first image with a blank alt field, type a description, save, click the next one. Repeat two hundred times. It feels productive — you're doing the work — but a one-by-one workflow almost never clears a real backlog, because new images arrive faster than one-at-a-time fixing can keep up.

Here's a short video on why the one-by-one approach stalls out and what a batch workflow does differently.

Why one-by-one feels like progress but isn't

Clicking through images one at a time gives you a real sense of motion — each save is a small win, and after an hour you can point to a number of images fixed. The problem is the maths underneath it. A typical WordPress site with a few years of content can easily hold several hundred images with missing or poor alt text. At a comfortable pace of one image every 30–60 seconds, clearing 300 images takes three to five hours of unbroken, repetitive clicking. Most people don't have five free hours for this in one sitting, so the work gets split across days or weeks — and during that time, new posts and product uploads keep adding images to the same pile.

The debt grows while you're paying it down. That's the core issue: one-by-one fixing is a rate of work, and if new images arrive at a similar or faster rate, the backlog never actually shrinks. It just moves.

What a batch workflow does differently

A batch workflow separates the work into two distinct phases instead of doing them one image at a time: scan first, then fix in groups.

Scan first. Before writing a single description, get a full count of what's missing across the whole site — not page by page, but site-wide. This turns an abstract sense of "there's probably a lot to do" into a concrete number, which matters because you can't plan a batch process around a guess.

Fix in groups, not individually. Instead of opening one image, writing text, saving, and repeating, a batch approach lets you review and approve descriptions for many images in one continuous pass — generate a first draft for a group, glance over each one, adjust where needed, and save the whole batch at once. The mental overhead of "open, think, write, save" per image disappears; you're reviewing rather than composing from scratch each time.

A worked example: 40 images in one sitting

Here's the practical difference in a single session:

Scan the media library and get a count — say, 40 images across the site with missing or empty alt text.
Generate a first-pass description for all 40 rather than one. Whether that's AI-drafted or written from a quick template, the point is producing a batch of drafts to review, not composing each one from a blank field.
Review the batch in one continuous pass. Scroll through the 40, checking each description against its image. Most will be fine as drafted; a handful will need a tweak.
Edit only the ones that need it. You're not retyping every description — you're correcting the minority that are wrong or too generic.
Save the batch. One action clears 40 images instead of 40 separate open-write-save cycles.

The same 40 images that would take 20–40 minutes of one-by-one work compress into a session that's mostly reviewing, not writing. That's the time saved — not from typing faster, but from cutting the repeated overhead of opening and closing each image individually.

Batch workflows also catch what one-by-one misses

There's a second benefit beyond speed: consistency. When you fix alt text one image at a time over several weeks, your standards drift. Descriptions written on a Monday in a hurry look different from ones written on a slower Friday — some too short, some too long, some missing the product name entirely.

Reviewing a batch side by side surfaces that inconsistency immediately. If three images in a row all describe products without naming the colour, that's a pattern you'd never notice fixing them individually across separate days, but it jumps out when they're in front of you together.

Making batch fixing an actual habit

A batch workflow only works if it happens on a schedule, otherwise the backlog reappears the same way it did before:

Pick a fixed cadence — weekly for an active site, monthly for a quieter one — and treat it like any other recurring maintenance task, not something you get to "when there's time." Scan first every time, even if you assume nothing's changed; new uploads add up faster than expected. And keep each session bounded — reviewing 40–60 images in one sitting is manageable; reviewing 300 in one go brings back the fatigue that made one-by-one fixing fail in the first place.

Frequently asked questions

How is a batch alt text workflow different from just working faster one image at a time?

Speed isn't the fix — structure is. One-by-one work repeats the full cycle (open, think, write, save) for every single image, and that per-image overhead is what makes it slow, not typing speed. A batch workflow separates scanning from fixing and lets you review many drafted descriptions in one continuous pass, cutting the repeated overhead rather than trying to do the same steps faster.

Won't reviewing AI-drafted alt text in a batch mean I miss mistakes?

Not if the review step is built in properly. A batch workflow doesn't mean accepting everything without looking — it means reviewing many drafts in one focused session instead of writing each one from scratch. You're still checking every description against its image; you're just spending that time reviewing instead of composing, which is faster and, done in one continuous pass, often more consistent than reviewing across many separate sessions.

How often should I run a batch alt text pass on my WordPress site?

It depends on how often you publish. A site adding new posts or products weekly benefits from a weekly scan-and-fix pass, so the backlog never grows past a manageable size. A quieter site might only need a monthly pass. The key is picking a cadence and sticking to it — an irregular schedule lets the backlog build back up to the point where a single session feels overwhelming again.

Try OpptiAI Alt Text to scan your WordPress media library and fix missing alt text in batches, or run a free image SEO audit to see how large your current backlog is.