DEV Community: Swift Labs

gpt-4o-mini-tts replacement: what to use after OpenAI shuts it down on Jan 6, 2027

Swift Labs — Mon, 09 Nov 2026 15:15:04 +0000

Originally published at tts.deadlinkpatrol.com. Facts checked November 9, 2026.

From Swift Labs, makers of TTS Swap. Written with AI help and checked against OpenAI's docs, OpenAI's community forum and our own service on November 9, 2026. Not affiliated with or endorsed by OpenAI.

Short answer: OpenAI shuts down gpt-4o-mini-tts on January 6, 2027, along with tts-1 and tts-1-hd. The replacement OpenAI lists is gpt-realtime-2.1-mini, which runs on the Realtime API, not on /v1/audio/speech. If your code only needs text in and audio out, an OpenAI-compatible endpoint keeps your audio.speech.create call running. TTS Swap does that, but it does not apply the instructions parameter, so tone and style prompts have no effect there.

What OpenAI says

OpenAI's deprecations page (entry "2026-10-01: Text-to-speech models") lists gpt-4o-mini-tts with a shutdown date of Jan 6, 2027 and gpt-realtime-2.1-mini as the recommended replacement.
OpenAI's text-to-speech guide says this is a change of API workflow: gpt-realtime-2.1-mini isn't a supported model for /v1/audio/speech. The guide's gpt-4o-mini-tts examples pass an instructions string such as "Speak in a cheerful and positive tone."
On OpenAI's community forum, OpenAI Support wrote on October 6 that migration means moving off /v1/audio/speech, and that you can set session.instructions or response.instructions on the Realtime API. Support also wrote on October 8 that the retirement notice doesn't name a drop-in replacement for /v1/audio/speech.
The same thread has users reporting that the Realtime path turns a few lines of code into far more, and that they want plain text in, speech out. Support said gpt-audio-1.5 through chat completions generates a response to a prompt and isn't guaranteed to read text verbatim.

So you can't just change gpt-4o-mini-tts to gpt-realtime-2.1-mini in audio.speech.create. That call isn't supported.

Find where you use it

grep -rnE "gpt-4o-mini-tts|instructions=" --include="*.py" --include="*.js" --include="*.ts" --include="*.env*" .

Check config files and environment variables too. The model name is often stored outside the code, and instructions is easy to miss.

Your options

Option	Keeps `/v1/audio/speech` code	`instructions` (tone, style)	Work involved
OpenAI Realtime API (`gpt-realtime-2.1-mini`)	No	`session.instructions` / `response.instructions`; test that it reads your text exactly	Rewrite to sessions and streamed events
Another speech provider with its own API	Usually no	Varies	New client code, new voices
An OpenAI-compatible speech server (hosted or self-hosted)	Yes	Varies by server; check	Change the base URL and API key
TTS Swap	Yes	Not applied	Change the base URL and API key

If you rely on instructions to set tone, accent or pacing, TTS Swap is not a match. Compare the Realtime API and other providers against your current output.

If you pass instructions but could live without it (internal tools, prototypes, accessibility read-aloud, batch narration), an OpenAI-compatible endpoint is the least work.

Using TTS Swap with gpt-4o-mini-tts code

TTS Swap answers the same /v1/audio/speech request. Change the base URL and API key; your calls can keep model="gpt-4o-mini-tts".

from openai import OpenAI

client = OpenAI(base_url="https://tts.deadlinkpatrol.com/v1", api_key="sk-tts-…")
client.audio.speech.create(model="gpt-4o-mini-tts", voice="alloy", input="Hello", response_format="wav").write_to_file("hello.wav")

Be clear on what you get:

instructions is not applied. Our service doesn't read that field. The request is not rejected: instructions is accepted but ignored, so it won't steer tone or style.
The voice won't sound like OpenAI's. Audio comes from the open-source MeloTTS model, with one voice per language. Every voice name gets that same voice.
WAV comes back even when you ask for mp3 (the default). pcm gives raw 24 kHz 16-bit mono. opus, aac and flac return a 400 error.
speed is accepted but not applied yet.
Languages: English by default; es, fr, zh, ja or ko via extra_body={"language":"es"}.
Limits: up to 4,096 characters per request. Paid keys are $19/month for 1,000,000 characters a month, 20 requests per minute per key. A shared daily capacity cap applies to the whole service. Over a limit you get an OpenAI-style 429.
Free key: 10,000 characters a month, 5 requests per minute, email only, no card. Free keys share a daily capacity limit, so on busy days they may get a 429 until 00:00 UTC.

Listen to the unedited samples on the home page before you decide.

FAQ

When does gpt-4o-mini-tts stop working?
January 6, 2027, according to OpenAI's deprecations page.

Can I just change gpt-4o-mini-tts to gpt-realtime-2.1-mini?
No. OpenAI's guide says gpt-realtime-2.1-mini isn't supported on /v1/audio/speech. It needs the Realtime API.

Does TTS Swap support the instructions parameter?
No. The field is ignored, so the output doesn't change with it.

Can I move back later?
Before January 6, 2027, yes: change the base URL and API key back to OpenAI's and keep using gpt-4o-mini-tts. After that date, gpt-4o-mini-tts is gone, so moving back means a supported OpenAI model and API workflow, or another compatible provider with that provider's matching key. Always change the URL and key together; a URL without its matching key fails with a 401.

Next steps

Get a free key or a paid key ($19/month) on the home page.
Copy-paste snippets: the gpt-4o-mini-tts migration guide.
Keeping the rest of your setup safe: Using OPENAI_BASE_URL to move text-to-speech off tts-1.

tts-1-hd replacement: what to use after OpenAI shuts it down on Jan 6, 2027

Swift Labs — Mon, 09 Nov 2026 13:21:58 +0000

Originally published at tts.deadlinkpatrol.com. Facts checked November 8, 2026.

From Swift Labs, makers of TTS Swap. Written with AI help and checked against OpenAI's docs and our own service on November 8, 2026. Not affiliated with or endorsed by OpenAI.

Short answer: OpenAI shuts down tts-1-hd on January 6, 2027, along with tts-1 and gpt-4o-mini-tts. The replacement OpenAI lists is gpt-realtime-2.1-mini, which runs on the Realtime API, not on /v1/audio/speech. If you picked tts-1-hd for its voice quality, compare samples from OpenAI's Realtime API and other providers against your current output. TTS Swap keeps your /v1/audio/speech code running; it uses MeloTTS, with no separate HD tier, so compare samples.

What OpenAI says

OpenAI's deprecations page (entry "2026-10-01: Text-to-speech models") lists tts-1-hd with a shutdown date of Jan 6, 2027 and gpt-realtime-2.1-mini as the recommended replacement.
OpenAI's text-to-speech guide says this is a change of API workflow: gpt-realtime-2.1-mini isn't a supported model for /v1/audio/speech. Existing Speech API integrations can keep working until shutdown.
The same guide describes tts-1 as lower latency but lower quality than tts-1-hd. That quality gap is why people chose HD, and it's what to check in any replacement.

So you can't just swap the model name from tts-1-hd to gpt-realtime-2.1-mini in audio.speech.create. That call isn't supported.

Find where you use it

grep -rnE "tts-1-hd" --include="*.py" --include="*.js" --include="*.ts" --include="*.env*" .

Check config files and environment variables too. The model name is often stored outside the code.

Your options

Option	Keeps `/v1/audio/speech` code	Voice quality	Work involved
OpenAI Realtime API (`gpt-realtime-2.1-mini`)	No	OpenAI voices	Rewrite to sessions and streamed events
Another speech provider with its own API	Usually no	Varies; compare samples	New client code, new voices
An OpenAI-compatible speech server (hosted or self-hosted)	Yes	Varies by model	Change the base URL and API key
TTS Swap	Yes	MeloTTS, one voice per language; no separate HD tier, so compare samples	Change the base URL and API key

If you chose tts-1-hd for how it sounds, compare samples from the Realtime API and other providers against your current output before you decide. Quality varies, and only your own listening test can tell you whether a replacement works for you.

If you mostly need the code to keep working (internal tools, prototypes, accessibility read-aloud, batch narration where voice quality matters less), an OpenAI-compatible endpoint is the least work.

Using TTS Swap with tts-1-hd code

TTS Swap answers the same /v1/audio/speech request. Change the base URL and API key; your calls can keep model="tts-1-hd".

from openai import OpenAI

client = OpenAI(base_url="https://tts.deadlinkpatrol.com/v1", api_key="sk-tts-…")
client.audio.speech.create(model="tts-1-hd", voice="alloy", input="Hello", response_format="wav").write_to_file("hello.wav")

Be clear on what you get:

MeloTTS; no separate HD tier, so compare samples. On TTS Swap, tts-1-hd gives the same output as tts-1.
The voice won't sound like OpenAI's. Audio comes from the open-source MeloTTS model, with one voice per language. Every voice name gets that same voice.
WAV comes back even when you ask for mp3 (the default). pcm gives raw 24 kHz 16-bit mono. opus, aac and flac return a 400 error.
speed is accepted but not applied yet.
Languages: English by default; es, fr, zh, ja or ko via extra_body={"language":"es"}.
Limits: up to 4,096 characters per request. Paid keys are $19/month for 1,000,000 characters a month, 20 requests per minute per key. A shared daily capacity cap applies to the whole service. Over a limit you get an OpenAI-style 429.
Free key: 10,000 characters a month, 5 requests per minute, email only, no card. Free keys share a daily capacity limit, so on busy days they may get a 429 until 00:00 UTC.

Listen to the unedited samples on the home page before you decide.

FAQ

When does tts-1-hd stop working?
January 6, 2027, according to OpenAI's deprecations page.

Can I just change tts-1-hd to gpt-realtime-2.1-mini?
No. OpenAI's guide says gpt-realtime-2.1-mini isn't supported on /v1/audio/speech. It needs the Realtime API.

Is there an HD version on TTS Swap?
No. tts-1-hd is accepted as a model name, but it produces the same MeloTTS audio as tts-1. There's no separate HD tier, so compare samples.

Can I move back later?
Before January 6, 2027, yes: change the base URL and API key back to OpenAI's and keep using tts-1-hd. After that date, tts-1-hd is gone, so moving back means a supported OpenAI model and API workflow (such as gpt-realtime-2.1-mini on the Realtime API), or another compatible provider with that provider's matching key. Always change the URL and key together; a URL without its matching key fails with a 401.

Next steps

Get a free key or a paid key ($19/month) on the home page.
Copy-paste snippets: the tts-1 migration guide.
Keeping the rest of your setup safe: Using OPENAI_BASE_URL to move text-to-speech off tts-1.

— Swift Labs. Migration guide: https://tts.deadlinkpatrol.com/migrate/tts-1?utm_source=devto&utm_medium=crosspost&utm_campaign=tts-1-hd-replacement

OpenAI's tts-1 shuts down Jan 6, 2027: your migration options, honestly compared

Swift Labs — Sat, 31 Oct 2026 15:04:07 +0000

Update (Nov 6, 2026): Swift Labs makes TTS Swap, one of the options compared below. It isn't affiliated with or endorsed by OpenAI. It now has a free key: 10,000 characters a month, email only, no card, 5 requests a minute. You can get it from the form on https://tts.deadlinkpatrol.com. Paid keys are $19/mo. To switch, you change the base URL and API key. There's a step-by-step migration guide with curl, Node and Python examples at https://tts.deadlinkpatrol.com/migrate/. The trade-offs are covered below: one voice per language, it returns WAV even when MP3 is requested, and speed isn't applied. If you need OpenAI's voices or other formats, its newer TTS models are still the better fit.

On January 6, 2027, OpenAI removes tts-1, tts-1-hd and both gpt-4o-mini-tts snapshots from its API (deprecations page, entry dated 2026-10-01). Those are every model that /v1/audio/speech serves today, so any client.audio.speech.create(...) call will start failing that day.

The catch: the official replacement, gpt-realtime-2.1-mini, does not run on /v1/audio/speech. OpenAI's own TTS guide says it's "a change of API workflow." Here is what that means and what your real options are.

1. Find every call site first

grep -rnE "audio\.speech|tts-1|gpt-4o-mini-tts|/v1/audio/speech" --include=*.{py,js,ts,go,rb} .

Also check config files and env vars where a model name may be stored. To monitor programmatically, GET /v1/models now exposes a shutdown_date field per model.

2. Option A: move to the Realtime API (OpenAI's path)

You open a Realtime session (WebSocket, WebRTC or SIP), send your text as an input_text conversation item, then call response.create with audio output and collect the audio deltas. Things to plan for:

It's a conversational model, not a reader. It responds to the prompt. OpenAI staff said in the community thread that the docs don't guarantee verbatim reading. Use strict instructions ("Read the following text exactly, add nothing") and test with your real inputs, especially text that contains questions.
Voices differ. fable, nova and onyx aren't in the current Realtime list. Map them before cutover.
More code. A stateless HTTP POST becomes a session lifecycle with streaming events and error handling.
Pricing units change from per-character to per-token (audio output tokens). Re-estimate cost with a sample of real traffic.

3. Option B: `gpt-audio-1.5` via Chat Completions

A single HTTP request to /v1/chat/completions with audio output, no WebSocket. Same verbatim caveat as above: it generates a response, so validate output on your inputs.

4. Option C: an OpenAI-compatible `/v1/audio/speech` provider

Many providers and self-hosted servers (e.g. Kokoro-FastAPI) accept the same request shape, so the migration is a base_url and API key change. Before you pick one, check:

Formats: does it really return MP3 when you ask for MP3, or something else?
Voices: do OpenAI voice names map to distinct voices or one voice?
Parameters: are speed and instructions applied or silently ignored?
Errors and limits: same 400/429 shapes so your retry logic still works?
Data handling: is your text stored?

5. A safe cutover checklist

Put the TTS base URL and model in config, not code.
Run old and new side by side on a fixed test set; compare duration, and transcribe the new audio to confirm the words match the input.
Check your audio pipeline handles the new format (WAV vs MP3 vs PCM).
Ship behind a flag well before Jan 6, then flip.

Disclosure: I'm with Swift Labs, and we run TTS Swap, one Option C provider: a base_url swap that keeps your audio.speech.create calls working. Be aware of its trade-offs: it uses the open-source MeloTTS voice (one voice per language, not OpenAI's voices), returns WAV even when MP3 is requested, and ignores speed for now. This article was drafted with AI assistance.

— Swift Labs

W-2 Box 12 Codes TP and TT: What a Payroll Export Needs for Tax Year 2026

Swift Labs — Sat, 31 Oct 2026 14:06:48 +0000

If you build or maintain anything that produces W-2 data (a payroll export, an HR tool, a year-end script for a small business), tax year 2026 adds two new Box 12 codes: TP for tips and TT for overtime. Here's what the IRS 2026 General Instructions for Forms W-2 and W-3 say each one holds, and what your data needs to compute them.

Educational, not tax advice. Check the current IRS instructions and a CPA, enrolled agent or payroll provider before you file.

Why the codes exist

Per the IRS instructions, P.L. 119-21 allows individuals a deduction for qualified tips and, for tax years beginning after 2024 and ending before 2029, a deduction of up to $12,500 ($25,000 if married filing jointly) for qualified overtime compensation. Employers report the amounts on the W-2 so workers can figure those deductions.

Code TP: total cash tips reported to the employer

The IRS wording: "Report the total amount of cash tips reported to the employer."

Two things matter for your data model:

Mandatory service charges are not qualified tips per the IRS instructions, so they generally stay out of TP. If your system lumps service charges and tips into one earnings type, you'll need to split them.
TP comes with an occupation code. When you report TP, you must also list an occupation code in Box 14b. So every employee with a TP amount needs an occupation code stored somewhere.

Code TT: total qualified overtime compensation

Per the IRS, qualified overtime is compensation paid to an individual required under section 7 of the Fair Labor Standards Act (FLSA) that is more than the regular rate at which the individual is employed. The IRS example: "only the 'half' portion of 'time-and-a-half' compensation would be reported using code TT."

For an hourly worker, a working estimate is FLSA overtime hours × regular rate × 0.5:

from decimal import Decimal, ROUND_HALF_UP

def tt_estimate(flsa_ot_hours: Decimal, regular_rate: Decimal) -> Decimal:
    """Premium ("half") portion of FLSA time-and-a-half overtime."""
    return (flsa_ot_hours * regular_rate * Decimal("0.5")).quantize(
        Decimal("0.01"), rounding=ROUND_HALF_UP
    )

# 10 FLSA overtime hours at a $20.00 regular rate -> 100.00 for code TT
print(tt_estimate(Decimal("10"), Decimal("20.00")))

Note what that function needs: overtime hours that were required by FLSA section 7, kept separately. Overtime paid only because of a state rule or a company policy isn't described by that definition, so if your payroll data stores all overtime in one bucket, that's the gap to close. Check with an advisor on edge cases.

The deadline

The due date for filing 2026 Forms W-2 and W-3 with the SSA is February 1, 2027, on paper or electronically. Reconciling TP and TT from the payroll register in December leaves time to fix gaps before forms go out, instead of filing W-2c corrections later.

Checklist for your export

Pull 2026 cash tips reported by each employee, excluding mandatory service charges.
Pull FLSA overtime hours and regular rates, and compute the premium (half) portion.
Make sure every employee with TP has a Box 14b occupation code.
Compare your totals with what the payroll provider will print.

Sources

Originally published on the Swift Labs W-2 guides site. This article was created with the help of AI and checked for accuracy before publishing.

How to Check Which WordPress Plugins Are Outdated on a Site, Without Logging In

Swift Labs — Thu, 29 Oct 2026 14:12:23 +0000

If you look after WordPress sites you can't log in to every week (client sites, a partner's site, a site you're about to quote on), you can still see a lot from the outside: which plugins the site loads and, for many of them, which version is installed. Here's how to do it by hand, and which signals to trust.

1. List the plugins the site loads

Open the home page, view the page source, and search for /wp-content/plugins/. The folder name after it is the plugin's slug, for example /wp-content/plugins/contact-form-7/. The slug is also the plugin's address on WordPress.org: wordpress.org/plugins/contact-form-7/.

This only finds plugins that load files on that page. Plugins that run only in the admin area, or only on other pages, won't show up.

2. Find the installed version from a reliable source

Two public signals are dependable:

The plugin's readme.txt. Many sites still serve /wp-content/plugins/<slug>/readme.txt. Its Stable tag: line normally matches the installed release.
A generator meta tag. Some plugins print their own version in the page head, for example <meta name="generator" content="Elementor 4.2.3">. Elementor, WooCommerce, Site Kit by Google and Slider Revolution do this.

If both are present they should agree. If they don't, treat the version as unknown.

# readme.txt Stable tag
curl -s https://example.com/wp-content/plugins/contact-form-7/readme.txt | grep -i "stable tag"

# generator tags in the page head
curl -s https://example.com/ | grep -io '<meta name="generator"[^>]*>'

3. Don't trust `?ver=` numbers

Script and stylesheet links often end in ?ver=1.2.3. That number is frequently the version of a bundled library, a theme setting or a cache-buster, not the plugin release. It's a hint at best. Reporting it as the installed version is how people end up telling a client a plugin is outdated when it isn't.

4. Compare with the latest release on WordPress.org

The plugin's WordPress.org page shows the current version. For scripting, the public plugins API is quicker:

curl -s -g "https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=contact-form-7" \
  | python3 -c 'import json,sys; print(json.load(sys.stdin)["version"])'

(-g stops curl from treating the square brackets as a URL glob.) If the installed version is lower, the plugin is outdated. Premium plugins that aren't on WordPress.org can't be compared this way.

5. Check WordPress core and PHP too

Core often shows in a generator tag (WordPress 6.9) or in the RSS feed at /feed/. Some servers send an X-Powered-By: PHP/8.1 header. php.net lists which PHP versions still get security fixes.

Checklist

[ ] Plugin slugs collected from /wp-content/plugins/ paths in the page source
[ ] Installed version taken from readme.txt Stable tag or a generator tag, never from ?ver= alone
[ ] Both signals agree (or the version is marked unknown)
[ ] Latest version taken from WordPress.org
[ ] Core and PHP checked where they're exposed

By hand this takes a few minutes per site, and plugins update constantly, so it's worth scripting if you do it for more than a handful of sites.

Originally published on WP Update Radar by Swift Labs, which runs these same outside-in checks on a list of sites each week.

This article was created with the help of AI and checked for accuracy before publishing.

The DMARC Record a Small Business Should Publish First (and When to Tighten It)

Swift Labs — Sat, 24 Oct 2026 16:10:30 +0000

If your business sends mail from its own domain (you@yourbusiness.com), three DNS records do the authentication work: SPF, DKIM and DMARC. SPF and DKIM prove a message came from a server you actually use. DMARC tells the receiving server what to do when a message claims to be from your domain but fails those checks, and where to send reports about it.

With no DMARC record, anyone can put your domain in the From: line of a phishing email. The receiving server has no instructions from you, and you never hear about it.

Start with one TXT record

At your DNS host (Cloudflare, GoDaddy, Squarespace, Network Solutions, or wherever your DNS lives), add:

Host/Name: _dmarc
Type:      TXT
Value:     v=DMARC1; p=none; rua=mailto:dmarc-reports@yourbusiness.com

Swap in a mailbox you really own. Some providers want the full name _dmarc.yourbusiness.com instead of just _dmarc.

p=none is monitoring mode. Nothing gets blocked or sent to spam, so it can't break your mail. It just starts the reports flowing so you can see who is sending as your domain.

The tags, and what a small business should do with them

Tag	Meaning	Suggested setting
`v=DMARC1`	Marks the record as DMARC; must come first	Always `v=DMARC1`
`p=`	Policy for failing mail: `none`, `quarantine` (spam folder), `reject` (block)	Start with `none`
`rua=`	Where daily aggregate reports go	A mailbox you own, or a monitoring service
`pct=`	Share of failing mail the policy applies to	Omit (defaults to 100) until you move to quarantine
`sp=`	Policy for subdomains	Omit; subdomains inherit `p=`
`adkim=` / `aspf=`	Strict or relaxed alignment	Omit; relaxed is the default and suits most setups
`ruf=`	Per-message forensic reports	Skip; few providers send them and they can include message content

Two mistakes that quietly make DMARC useless

1. p=none with no rua=. v=DMARC1; p=none; is valid but does nothing: no protection, no reports. Checkers still mark it "present", so it looks finished. Add a rua= address.

2. Two DMARC records. If _dmarc.yourbusiness.com has two TXT records starting with v=DMARC1, receivers treat the domain as having no DMARC at all. Merge them into one. This often happens when a website builder or email provider adds its own record next to yours.

Get SPF and DKIM right first

DMARC passes when a message passes SPF or DKIM and the passing domain matches the From: domain. Before tightening anything:

SPF: a single TXT record at the root of the domain starting with v=spf1, listing every service that sends as you (e.g. include:_spf.google.com for Google Workspace, include:spf.protection.outlook.com for Microsoft 365). Only one SPF record is allowed, and it has to stay under 10 DNS lookups.
DKIM: turn it on in your mail provider's admin console and publish the DNS records it gives you.

Then list everything else that sends as your domain: newsletter tool, invoicing or booking software, CRM, website contact forms. Each needs SPF or DKIM set up for your domain, or it will fail once you enforce DMARC.

Is DMARC required for a small sender?

Gmail's sender guidelines require everyone sending to personal Gmail accounts to use SPF or DKIM. Senders of more than 5,000 messages a day must also publish DMARC, and p=none is acceptable. Most small businesses are far below 5,000 a day, so strictly speaking they don't need it.

Google still recommends SPF, DKIM and DMARC for every domain, and DMARC reports are the only way to see who is sending mail under your name. It costs one DNS record, and at p=none there's no risk to your own mail.

Moving from p=none to quarantine and reject

Collect at least two to four weeks of reports at p=none, then:

Confirm every legitimate sender passes. Each service you use should show SPF or DKIM passing and aligned in the reports. Fix the ones that don't.
Step into quarantine gradually, e.g. v=DMARC1; p=quarantine; pct=25; rua=mailto:..., raising pct to 100 over a couple of weeks while you watch the reports.
Switch to reject once quarantine at 100% has run cleanly: v=DMARC1; p=reject; rua=mailto:....

Reading the reports

Aggregate reports arrive as compressed XML attachments, typically one a day from each large mailbox provider that received your mail. They're painful to read by hand. You can parse them yourself, or point rua= at a service that reads them for you. DMARC allows several rua addresses separated by commas, so you can keep your own mailbox in the list.

Checklist

[ ] One TXT record at _dmarc.yourbusiness.com starting with v=DMARC1
[ ] p=none to start
[ ] rua=mailto: pointing at a mailbox you read, or a monitoring service
[ ] One SPF record, under 10 lookups, covering every sender
[ ] DKIM enabled with your mail provider and each sending tool
[ ] 2-4 weeks of reports reviewed before p=quarantine

Sources: Gmail email sender guidelines (support.google.com/a/answer/81126); DMARC tag definitions and multiple-record handling per RFC 7489 §6.3 and §6.6.3.

Originally published on Email DNS Check, a free SPF/DKIM/DMARC checker by Swift Labs. We also build MailGuard, which reads DMARC reports and sends a plain-English weekly summary ($7/domain/month, 14-day trial).

This article was created with the help of AI and checked for accuracy before publishing.

How Often Should You Check for Broken Links? A Schedule by Site Type

Swift Labs — Fri, 23 Oct 2026 14:08:39 +0000

"Check your links regularly" is common advice that doesn't tell you much. Regularly could mean every day or once a year. The honest answer is that the right schedule depends on how quickly your site can break, and that comes down to two things: how often you change it, and how many links point to things you don't control.

This guide lays out a schedule by site type, lists the events that should trigger a check no matter what the schedule says, and explains why "how often" matters less than "what happens after the check."

Why links break in the first place

To pick a schedule, it helps to know where breakage actually comes from. Almost all of it has one of five causes:

You changed something. You renamed a page, changed a slug, removed a product, restructured the menu, or switched themes. This is the most common cause of internal broken links, and it happens right when you make the change.
A migration or redesign. This is the same as the first cause but at scale. Changes to URL patterns (/blog/post-name becoming /post-name, .html extensions dropped, category bases changed) can break hundreds of links in one go.
Someone else changed something. External sites you link to delete pages, restructure, or shut down. This is "link rot." It happens gradually, and you have no warning.
Content editors paste bad links. A missing https:// makes a link relative, so example.com on /about/ turns into /about/example.com and returns a 404. A typo or a staging URL left in a post does the same.
Files and media go missing. PDFs get replaced with new filenames, images are deleted from the media library, and CDN paths change.

Causes 1, 2, 4 and 5 happen when you change something, so you can catch them by checking after the change. Cause 3 happens at random, so you can only catch it by checking on a schedule. A good routine handles both.

A starting schedule by site type

These are sensible defaults, not rules. Change them based on what your first few scans turn up (more on that below).

Small brochure site (under ~50 pages, edited a few times a year)

Monthly scheduled check, plus a check after any edit session.

A local plumber's five-page site doesn't change much. Its internal links break only when someone edits it, so a scan after edits catches most problems. A monthly scan picks up external link rot (links to suppliers, certification bodies, review profiles) and any changes the host or platform made without telling you.

Active blog or content site (new posts weekly)

Weekly check.

Every new post adds links, and older posts link to external sources that rot over time. The more content a site has, the more external links it has, and the more rot each month. Weekly is usually enough. If you publish every day, look for a checker that can scan new pages as they go live.

E-commerce store

Weekly at minimum. Daily if products change often.

Stores change all the time. Products sell out and get removed, collections get reorganized, and seasonal landing pages expire. Each removed product URL can leave broken links in category pages, blog posts that mention it, and emails. On a store, a broken link means a lost sale, so it costs more than it would on a brochure site.

Large site, or a site with frequent deploys

Daily.

If the site has thousands of pages, several editors, or a development team that deploys several times a week, things break between scans often enough that weekly checks let problems sit for days. Daily scans that only alert on new breakage are the norm here. Without diffing, a daily report becomes noise.

Agencies managing client sites

Daily for every site under a care plan, with weekly or monthly reporting to the client.

The schedule and the report don't have to match. Checking daily means you find out about a break before the client does. Reporting monthly gives the client a summary they'll actually read. If you're charging for maintenance, finding out from the client that their booking page has been a 404 for two weeks is the outcome you most want to avoid.

Documentation and knowledge bases

On every build, plus a weekly scan of the live site.

Docs are full of cross-references and links to API references, code repositories and release notes, all of which move. Build-time checks catch internal mistakes before they ship. The weekly live scan catches external rot and anything the build check can't see, like redirects added at the server level.

Events that should trigger a check right away

Whatever your schedule, scan as soon as possible after any of these:

A site migration or redesign. Scan the old site before the switch so you have a list of URLs, then scan the new site straight after launch. Every old URL that now 404s needs a 301 redirect or a reason it doesn't.
A change to the URL structure. Permalink settings, category bases, trailing slashes, language prefixes.
A theme or page-builder change. Menus, footers and widgets often get rebuilt, and their links can quietly change.
Bulk deletion. Discontinued products, old events, expired job posts.
A domain change or HTTPS move. Hard-coded absolute URLs in content are a classic source of breakage.
A CMS or plugin update that touches routing. This doesn't happen often, but when it does it hits every page.
Any time you get an unexplained traffic drop on specific pages.

If your checker has an API, wire a scan into your deploy pipeline so a scan starts as part of every deploy.

How to tune the schedule after a month

Your first scan is a baseline, and it will probably find a backlog. Fix that first. After that, watch how much new breakage turns up between scans:

What you see between scans	What it suggests
Almost never anything new	Your schedule is fine, or you could scan less often
A few new external breaks each time	Normal link rot, so keep the schedule
New internal breaks most times	Edits are breaking things, so scan more often or add post-edit checks
Bursts of new breaks after deploys	Add a scan to your deploy process
Lots of 403/429/timeouts on the same external sites	Those sites block bots. Exclude them or verify them by hand

The aim is that each scan turns up a small, manageable number of genuinely new problems. If every report is huge, either the backlog hasn't been cleared or the schedule is too infrequent for how fast the site changes.

What matters more than frequency

A daily scan that nobody reads is worth less than a monthly scan that someone acts on. Three things decide whether a checking routine actually keeps links working:

1. Only alert on what's new. If every report repeats last week's known issues, people stop reading them. Use a checker that compares each run against the previous one, or keep your own list of known issues and alert only on the difference.

2. Verify before you alert. External sites go down briefly, and some answer automated requests with errors while working fine in a browser. A good checker rechecks a failure before reporting it. A rule we use ourselves: only count a link as broken if it returns 404 or 410 on two separate requests. One failed request isn't enough to call a link broken.

3. Give the fix an owner. Every report should go to someone whose job includes fixing it. On an agency team, that means routing each client's alerts to the person who manages that client.

Does Google care how quickly you fix broken links?

Google's own documentation is useful here. Its Search Console help says that 404 responses "are not necessarily a problem, if the page has been removed without any replacement," and that if a page has moved, you should "use a 301 redirect to the new location." Its developer docs explain that URLs returning a 4xx status are removed from the index, and that Googlebot crawls them less often over time.

So a broken link isn't a penalty in itself. The real cost is what the link would have done: a visitor who reaches a dead end instead of a product page, internal link value that leads nowhere, or a page that dropped out of the index because it moved without a redirect. Those costs add up the longer the link stays broken, so the useful question is how long you're willing to let a broken link hurt you before you notice. If the answer is "no more than a day" for your checkout and contact pages, those pages need daily checks, whatever you do with the rest of the site.

A simple setup that covers most sites

If you'd rather not think about any of this:

Run a full scan today and fix everything it finds.
Schedule automatic scans: monthly for small static sites, weekly for blogs and stores, daily for large sites and client sites you're paid to maintain.
Make sure alerts only fire for new breakage.
Add a manual scan to your checklist for launches, migrations and theme changes.
Look at the numbers after a month and adjust.

Originally published on the DeadLinkPatrol blog. We build DeadLinkPatrol, a scheduled broken-link checker. If you want to see what a live crawl finds on your own site, the free checker scans up to 25 pages without signup.

This article was created with the help of AI and checked for accuracy before publishing.

Broken Link Checking for Docs Sites: Build-Time Checks Plus Live Monitoring

Swift Labs — Wed, 21 Oct 2026 14:08:55 +0000

Documentation sites are hard on links. They're full of cross-references between pages, anchors to specific sections, links to API references, code repositories, changelogs and third-party docs, and all of those move. Pages get renamed when the product changes, versions get archived, and the external projects you link to restructure their own docs. A reader who follows a "see Configuration" link and lands on a 404 in the middle of a task is a frustrated reader, and often becomes a support ticket.

The good news is that docs teams have better tools for this than most websites, because docs are usually built from source files. The catch is that build-time checks only catch some problems. This guide covers both halves: what to check during the build, and what you can only catch by checking the live site.

The three kinds of broken docs links

It helps to separate them, because different tools catch each kind.

Internal page links. A link from one doc page to another that doesn't exist (renamed file, deleted page, typo in a relative path). Your static site generator can catch these at build time, because it knows every page that exists.
Anchor links. A link to /config#retry-options when the heading is now "Retry settings", so the anchor is #retry-settings. The page loads, so nothing returns a 404, but the reader lands at the top of a long page instead of the section they wanted. Some generators can check these. Many link checkers ignore them.
External links. Links to GitHub, package registries, other projects' docs, blog posts and standards. Your build can't know whether these work, so you need a checker that makes real HTTP requests, and those links can break at any time after you deploy.

There's a fourth, sneakier kind: links that work in the build but break in production. Server-level redirects, a base path that's different in production, a CDN rule, or a versioned-docs setup where old versions point at pages that only exist in the latest version. Only a check against the live site finds these.

Layer 1: Turn on your generator's own checks

Start here. It's free and takes a few minutes. Exact option names vary between versions, so check your generator's docs for the version you run.

Docusaurus

Docusaurus checks internal links when you run a production build, and the onBrokenLinks option in docusaurus.config.js controls what happens when it finds one. In current versions the default is 'throw', which fails the build. Keep it that way. There are related options for broken Markdown file links and for broken anchors (onBrokenAnchors, which defaults to a warning in the versions that have it). If you can, set anchors to throw as well, so renamed headings fail the build instead of quietly sending readers to the top of the page.

Note that these checks happen during docusaurus build, not in the dev server, so make sure CI runs a real build on every pull request.

MkDocs

Run mkdocs build --strict in CI. Strict mode turns warnings, including warnings about links to documentation files that don't exist, into a failed build. Recent MkDocs versions also have a validation section in mkdocs.yml that controls how strictly different link problems are treated, including anchors. MkDocs validates links between your Markdown files. It doesn't check external URLs.

Sphinx

Sphinx warns about broken cross-references during a normal build (-W turns warnings into errors, and -n "nitpicky" mode reports missing references more aggressively). For external URLs it ships a dedicated builder: sphinx-build -b linkcheck (or make linkcheck) requests every external link and writes a report. It's slow on large sites, so most teams run it on a schedule rather than on every commit.

Hugo

Hugo's ref and relref shortcodes fail or warn (depending on refLinksErrorLevel) when they point at a page that doesn't exist. Plain Markdown links aren't checked, so teams that care use ref/relref for internal links and an external checker for everything else.

Everything else (GitBook, Mintlify, ReadMe, custom setups)

Hosted docs platforms vary a lot. Some flag broken internal links in their editor, some don't, and few check external links on a schedule. If yours doesn't, you'll rely more on Layers 2 and 3.

Layer 2: Run a link checker in CI

Build checks handle internal links. For external links, add a dedicated link checker to your CI pipeline. Common choices:

lychee, a fast link checker written in Rust that works on Markdown, HTML and plain text. It has an official GitHub Action (lycheeverse/lychee-action) and supports caching, exclusions and retries.
markdown-link-check, a Node tool that checks links in Markdown files and is popular in smaller repos.
Generator-specific actions, such as the MkDocs link-check GitHub Action, which wrap a checker with sensible defaults for that generator.

A few lessons that save a lot of frustration:

Don't block pull requests on external links. An external site going down for ten minutes shouldn't stop someone merging a typo fix. Block PRs on internal link failures (Layer 1). Run external checks on a schedule or as a non-blocking job, and open an issue when something fails.

Expect bot-blocking. Some sites answer automated requests with 403, 429 or other non-200 codes while working fine in a browser. Social networks and some large platforms are known for it. Keep an exclusion list for known false positives, and review it every few months, because "excluded" can quietly turn into "never checked."

Retry before failing. Use your checker's retry settings, or have it check twice before reporting. A single timeout isn't a broken link.

Use caching on a schedule. Checking every external link in a large docs repo on every run is slow and can get you rate-limited. Caching results for a day or so is a reasonable compromise.

Layer 3: Monitor the live site

Layers 1 and 2 check your source. Your readers use the deployed site, and the two differ more than you'd think:

Redirects and rewrites set up in your host, CDN or reverse proxy don't exist in the build environment.
Base paths and versioning. Docs served under /docs/v2/ can behave differently from the local build, especially with versioned docs where old versions link to paths that only exist in newer ones.
Generated content. API references generated from code, embedded changelogs or content pulled in at deploy time may never be seen by the source checker.
Things that break after deploy. Every external link you checked at build time can break next week. If you only check on commits, a docs section nobody edits never gets rechecked.
Assets. Images, downloadable files and embedded media served from a separate bucket or CDN.

A scheduled crawl of the live site catches all of these. It works the way a reader does: it starts at your docs homepage, follows links, and records every link and image that returns an error, along with the page it was found on. Weekly is enough for most docs sites. If you deploy docs many times a day, run it daily and alert only on new breakage, so the alerts don't become noise.

Any crawler that records the "found on" page for each broken link works here: a scheduled lychee run against the deployed URL, a hosted monitor, or a small script of your own. What matters is that it hits the live site, rechecks failures before reporting them, and compares each run with the previous one.

Docs-specific habits that prevent breakage

Redirect when you rename. Most docs platforms and hosts support redirect maps. Make "add a redirect" part of the checklist for renaming or moving any page, the same way you'd update the sidebar. Old docs URLs get bookmarked, linked from forum answers and Stack Overflow, and cited in other projects' docs, so they need to keep working.

Link to stable URLs. For external references, prefer permalinks: tagged release URLs instead of main branch file links (which break when files move), versioned API docs instead of "latest" where the content matters, and DOIs or archived copies for papers and specs.

Link to headings deliberately. If your generator lets you set explicit heading IDs, use them for sections that get linked often. Then changing the heading text doesn't change the anchor.

Keep an eye on archived versions. Versioned docs multiply your link count. Decide how far back you'll maintain links. For versions you've frozen, you can exclude external links from checks and add a banner pointing readers to the current version.

Give link reports an owner. Route scheduled link failures to a real place, such as a docs issue label, a Slack channel or a weekly triage, with a named owner. A report nobody owns gets ignored.

A setup that covers all three layers

Every pull request: production build with the generator's broken-link checks set to fail (internal pages, plus anchors if supported).
Nightly or weekly in CI: lychee or similar against the source for external links, non-blocking, opening an issue when something fails.
Weekly (daily if you deploy often): a crawl of the live docs site, alerting only on new breakage, with the "found on" page included.
Always: redirects for moved pages, stable external URLs, and explicit IDs for frequently linked headings.

This article was created with the help of AI and checked for accuracy before publishing.

Search Console "Not Found (404)" Errors: Which to Fix and Which to Ignore

Swift Labs — Mon, 19 Oct 2026 07:34:44 +0000

Open the Page indexing report in Google Search Console on almost any site that has been around for a while and you'll find a "Not found (404)" row, sometimes with hundreds or thousands of URLs. It looks like an emergency. Most of the time it isn't, but a few of those URLs probably do matter, and the trick is to work out which ones.

This guide explains what Google actually says about 404s, gives you a simple triage to sort the list into "fix", "redirect" and "leave alone", and shows how to stop the list from growing.

What Google says about 404s

It's worth starting from Google's own documentation rather than SEO folklore.

In the Search Console help for the Page indexing report, Google describes a "Not found (404)" URL as one that "returned a 404 error when requested," discovered "without any explicit request or sitemap," possibly "as a link from another page, or possibly the page existed before and was deleted." It then says plainly: "404 responses are not necessarily a problem, if the page has been removed without any replacement. If your page has moved, use a 301 redirect to the new location." It also notes that Googlebot "will probably continue to try this URL for some period of time" and "will crawl it less and less often."

Google's developer documentation on HTTP status codes adds that all 4xx errors except 429 are treated the same way: the URL is removed from the index if it was indexed before, "newly encountered 404 pages aren't processed," and "the crawling frequency gradually decreases."

That gives you two practical conclusions:

A 404 is the correct response for a page that's genuinely gone. Returning one doesn't penalize your site.
A 404 on a URL that should work is a real problem. It's not a penalty either, but the page drops out of the index and any traffic or link value it had is lost.

So you're not trying to get the 404 count to zero. You're trying to find the 404s that shouldn't be 404s.

Step 1: Export the list

In Search Console, go to Indexing → Pages, click the Not found (404) row, and export the examples. Search Console shows a sample of affected URLs, not necessarily every one, so treat the export as a starting point rather than a full inventory.

Add two columns to the spreadsheet: Category and Action.

Step 2: Sort every URL into one of five buckets

Go through the list (filter by URL pattern to speed it up) and put each URL into one of these buckets.

Bucket A: Pages that moved and still have an equivalent

A product renamed from /blue-widget to /widgets/blue. A blog post whose slug changed. A service page merged into another service page.

Action: 301 redirect to the closest equivalent. This is exactly what Google's help recommends, and it's the most valuable fix on the list, because these URLs often had rankings, backlinks, or both.

Bucket B: Pages deleted on purpose with no replacement

A discontinued product with no successor. An event from 2019. A job ad that has been filled.

Action: leave it as a 404 (or a 410 if you want to signal "gone for good"). Don't redirect these to the homepage. Google tends to treat irrelevant redirects like that as soft 404s anyway, and users who land on your homepage instead of what they clicked get confused. If the deleted page had good backlinks and there's a genuinely related page, such as the category it belonged to, a redirect there is reasonable.

Bucket C: URLs that never existed

Typos in links on other sites, URLs with junk parameters, spam bots probing /wp-login.php on a site that isn't WordPress, paths with tracking garbage tacked on.

Action: ignore. You don't control other people's typos, and these URLs never had value. The exception is a typo'd URL that has a strong backlink pointing at it. A redirect to the intended page recovers that value.

Bucket D: URLs created by your own broken links

This is the bucket people miss. The URL is in Search Console because your own site links to it. Common causes:

A link edited in one place but not in another (old menu item, footer, sidebar widget)
A relative link missing its protocol: an editor types example.com/page instead of https://example.com/page, and the browser resolves it relative to the current page, so you get /about/example.com/page
A template that builds URLs from data that's sometimes empty (/products/ + nothing)
Links in old blog posts pointing at pages that have since moved

Action: fix the link at the source, and add a redirect if the URL has external value. A redirect alone isn't enough. If your own pages link to a 404, every visitor who clicks it hits a dead end, and internal links pass through a redirect hop for no reason. Find the page that contains the link and edit it.

Search Console's URL Inspection tool can sometimes show you where Google found a URL, but it doesn't reliably list every page that links to it. A crawler that records the source page for every broken link, the "found on" page, is the faster way to find these.

Bucket E: URLs that should work but don't

The URL is correct, the page should exist, and it returns 404 anyway. Typical causes are a deployment that dropped a route, a CMS page set to draft by mistake, a permalink flush that didn't run, or a server rule that's too broad.

Action: fix the page itself. This is a bug, not a content decision. If a Bucket E URL is a revenue page (pricing, checkout, contact, booking), it's the most urgent item on the whole list.

Step 3: Prioritize

With everything bucketed, work in this order:

Bucket E on important pages. Broken pages that should be working.
Bucket D. Your own links pointing at 404s, starting with sitewide elements (menus, footers), because one fix there repairs hundreds of instances.
Bucket A, ordered by value. If you can see which moved URLs had traffic (in analytics or Search Console's performance report) or backlinks (in any backlink tool), redirect those first.
Bucket C typos with strong backlinks.
Everything else in B and C: nothing to do.

On a typical site, steps 1 and 2 involve a fairly short list and do most of the good.

Step 4: Validate and wait

After fixing, you can use Validate fix on the Not found (404) row in Search Console. Expect it to take a while. Google rechecks on its own schedule, and the help docs say Googlebot keeps trying removed URLs "for some period of time." URLs you intentionally left as 404s will stay in the report for a while, and that's fine.

Don't judge your work by whether the 404 count goes down. Judge it by whether the URLs in buckets A, D and E now resolve correctly.

Why Search Console alone isn't enough

Search Console is a good lagging indicator, but it has gaps for this job:

It's slow. URLs show up after Googlebot crawls them, which can be days or weeks after a link broke.
It's a sample. The export won't necessarily include every affected URL.
It only sees what Google crawls. It won't show broken links in pages Google skips, in noindexed sections, or links to external sites that have died. Your visitors still click those.
It mixes good 404s with bad ones. You have to do the triage above every time.

A scheduled link crawler fills these gaps. It works from your side: it crawls your pages, checks every link it finds, and tells you which page each broken link sits on, usually within a day of the break. That turns Bucket D from detective work into a to-do list.

Stopping new 404s from building up

A few habits keep the report small:

Redirect when you rename. Make "add a 301" part of the process for changing any published URL. Most CMSs have redirect plugins or settings.
Scan after big changes. Migrations, redesigns, permalink changes and bulk deletions all need a crawl before and after.
Paste full URLs. Train editors to paste links with https://, or use a CMS link picker for internal links.
Monitor on a schedule. Weekly for most sites, daily for stores and client sites you're paid to maintain, with alerts only for new breakage.
Check your sitemap. A sitemap that lists 404 URLs sends Google mixed signals. Regenerate it after deletions.

The short version

404s for pages that are really gone are normal. Google says so.
Redirect moved pages to their closest equivalent with a 301.
Fix your own links that point to 404s at the source. This is the most commonly missed fix.
Treat a 404 on a page that should exist as a bug, and fix it first.
Ignore typos and junk URLs unless they carry real backlinks.
Use a crawler that records the "found on" page, so you can see where the broken links come from without waiting for Google.

This article was created with the help of AI and checked for accuracy before publishing.

DEV Community: Swift Labs

gpt-4o-mini-tts replacement: what to use after OpenAI shuts it down on Jan 6, 2027

What OpenAI says

Find where you use it

Your options

Using TTS Swap with gpt-4o-mini-tts code

FAQ

Next steps

tts-1-hd replacement: what to use after OpenAI shuts it down on Jan 6, 2027

What OpenAI says

Find where you use it

Your options

Using TTS Swap with tts-1-hd code

FAQ

Next steps

OpenAI's tts-1 shuts down Jan 6, 2027: your migration options, honestly compared

1. Find every call site first

2. Option A: move to the Realtime API (OpenAI's path)

3. Option B: gpt-audio-1.5 via Chat Completions

4. Option C: an OpenAI-compatible /v1/audio/speech provider

5. A safe cutover checklist

W-2 Box 12 Codes TP and TT: What a Payroll Export Needs for Tax Year 2026

Why the codes exist

Code TP: total cash tips reported to the employer

Code TT: total qualified overtime compensation

The deadline

Checklist for your export

Sources

How to Check Which WordPress Plugins Are Outdated on a Site, Without Logging In

1. List the plugins the site loads

2. Find the installed version from a reliable source

3. Don't trust ?ver= numbers

4. Compare with the latest release on WordPress.org

5. Check WordPress core and PHP too

Checklist

The DMARC Record a Small Business Should Publish First (and When to Tighten It)

Start with one TXT record

The tags, and what a small business should do with them

Two mistakes that quietly make DMARC useless

Get SPF and DKIM right first

Is DMARC required for a small sender?

Moving from p=none to quarantine and reject

Reading the reports

Checklist

How Often Should You Check for Broken Links? A Schedule by Site Type

Why links break in the first place

A starting schedule by site type

Small brochure site (under ~50 pages, edited a few times a year)

Active blog or content site (new posts weekly)

E-commerce store

Large site, or a site with frequent deploys

Agencies managing client sites

Documentation and knowledge bases

Events that should trigger a check right away

How to tune the schedule after a month

What matters more than frequency

Does Google care how quickly you fix broken links?

A simple setup that covers most sites

Broken Link Checking for Docs Sites: Build-Time Checks Plus Live Monitoring

The three kinds of broken docs links

Layer 1: Turn on your generator's own checks

Docusaurus

MkDocs

Sphinx

Hugo

Everything else (GitBook, Mintlify, ReadMe, custom setups)

Layer 2: Run a link checker in CI

Layer 3: Monitor the live site

Docs-specific habits that prevent breakage

A setup that covers all three layers

Search Console "Not Found (404)" Errors: Which to Fix and Which to Ignore

What Google says about 404s

Step 1: Export the list

Step 2: Sort every URL into one of five buckets

Bucket A: Pages that moved and still have an equivalent

Bucket B: Pages deleted on purpose with no replacement

Bucket C: URLs that never existed

Bucket D: URLs created by your own broken links

Bucket E: URLs that should work but don't

Step 3: Prioritize

3. Option B: `gpt-audio-1.5` via Chat Completions

4. Option C: an OpenAI-compatible `/v1/audio/speech` provider

3. Don't trust `?ver=` numbers