Internet Marketer Ivan Tan

Blog

  • My Content Repurposing Workflow: One Post, Five Formats

    My Content Repurposing Workflow: One Post, Five Formats

    One blog post should leave the house as five pieces of content, and the trick is that you never write any of them from scratch. After the article is published I spend about 45 minutes cutting the same material into a newsletter, a short video script, a social post, and a forum answer. Each format pulls from a different layer of the post, which is why the words come out fast and still sound like they were written for that place.

    I covered the writing half of this in How to Write a Blog Post in 90 Minutes. This is the second half: what happens to the file after I hit publish.

    The short version

    • Treat the finished post as raw material, not a monument. Every other format is a cut of it.
    • Each cut takes a different layer: the promise, the skeleton, the proof, or one quotable sentence.
    • Give each format one job. Newsletter for relationship, video for reach, social for distribution, forum for credibility.
    • Do all four cuts in one sitting, while the thinking is still in your head.
    • Five formats is a ceiling, not a quota. Skipping one is a decision, not a failure.

    Start from layers, not from a blank page

    Most repurposing fails because people open a new document and try to write a post about the article. That is a rewrite with extra steps. The faster path is to accept that the post contains everything you need, just packed for one reader in one mood.

    Before I cut anything, I break the article into four layers:

    • The promise — the sentence in the intro that says what the reader gets. It becomes the newsletter subject line and the first line of the social post.
    • The skeleton — the H2 headings. They become the video beats, because they are already an ordered argument.
    • The proof — the steps, commands, settings, or examples. They become the forum answer.
    • The quotable line — the one sentence I would underline. It becomes the opening line of the video and the hook of the social post.

    Once those four things exist, repurposing is selection, not creation. That is the whole trick.

    The five cuts, in order

    This is the shape I work to. The times are what the cutting takes me once the article is live, not the time to write the article.

    Format Cut from Time Job
    Blog post (source) Outline and draft 90 min The asset you own and can rank
    Newsletter Promise and skeleton 10 min Relationship with people who opted in
    Short video script Skeleton and proof 10 min Reach on a platform you do not own
    Social post Quotable line and link 5 min Distribution to people who will never subscribe
    Forum answer Proof section 15 min Credibility where the question is already being asked

    The newsletter: send the promise, not the post

    The mistake here is pasting the whole intro and calling it a newsletter. People subscribed to hear from you, not to get a second copy of a page they can read for free. I send 150 to 250 words: the promise, three bullets from the skeleton, and one link. If I cannot explain the value in three bullets, the article probably has more than one idea in it.

    Subject: [the promise, rewritten as a question or a number]

One sentence on why this matters this week.

- The problem, in the reader's words
- The step most people skip
- What to do first

Full post: [link]

That is the whole email. No preamble, no signature block longer than one line.

    Two rules: the subject line describes what is inside, and the bullets are useful on their own. A newsletter that only works if you click is an ad.

    The video script: your headings are already the beats

    A 30 to 45 second script does not need a scriptwriter. It needs three beats, and the article already has them. I take the problem from the intro, the method from the first two or three H2s, and the proof from whatever concrete example the post contains. Then I write it as spoken lines, one idea per line, eight to ten words each.

    The shape that works for me:

    • Beat 1, problem (0–5s): the viewer’s own complaint, said plainly. No greeting, no “in this video”.
    • Beat 2, method (5–25s): the two or three steps, in order, with the reason attached to each one.
    • Beat 3, proof (25–35s): the specific result from the post — the log line, the setting, the thing that changed.
    • Close (35–40s): one action, one place to go.

    If a beat needs a diagram to make sense, it belongs in the post.

    The social post: lift one paragraph and stop

    Social is not a summary. A summary of a long article is boring in every format. What travels is one opinionated sentence, stated without hedging, followed by enough context to be useful and a link for the people who want the rest.

    My routine: pick the most contrary sentence in the article, paste it first, delete every word that softens it, then add one line of value and the link. On X the limit is 272 weighted characters and a link counts as 23, so the real text budget is around 250. No hashtags there; they read as spam. On LinkedIn or Facebook I add a line break before the link so the post does not end in a wall of URL.

    What I never do is announce that I wrote a blog post. Nobody owes me a click because I was productive. The sentence has to earn it.

    The forum answer: answer first, link second

    Forums are where the same question gets asked every week, and the easiest place to be useful if you resist advertising. I find a thread where I actually know the answer, then write the answer as if my site did not exist. Only at the end, if there is more detail than a forum reply should carry, do I mention that I wrote it up in full.

    Practical version: lead with the direct answer in the first two lines, give the steps in the order you would do them, and name the one thing that usually goes wrong. Strip the brand voice completely. A forum reader can smell a marketing line in the first sentence, and then the answer is dead no matter how correct it is.

    What I skip, and why five is a ceiling

    Not every post deserves five cuts. Some topics are useful and quiet; they earn a newsletter mention and nothing else. Others are already saturated on video and do better as a written reference. I decide based on where the question lives, not on a content calendar that says every post gets five assets.

    Things I skip by default: Instagram carousels, because the design time eats the writing time; podcast appearances, because they are a different skill; and old forum threads. Things I only do when the post is genuinely strong: a second video, a longer LinkedIn version, and a follow-up article that goes deeper on one section.

    Two weeks after publishing, I check which pieces earned impressions and which earned nothing, then put the next month’s effort where the numbers actually moved. That is a Google Search Console habit, and I wrote the setup for it in How to Set Up Google Search Console Properly. Repurposing without that check is just making more things.

    The 45-minute checklist

    1. Copy the promise sentence and the H2 list into one scratch file.
    2. Write the newsletter from those two things only. No new ideas.
    3. Turn the H2 list into three video beats and one closing action.
    4. Lift one paragraph for social, cut it until it fits, add the link last.
    5. Find one real question and answer it with the proof section, brand voice off.
    6. Schedule all four and log them in a single row of a spreadsheet: date, post, formats, links.
    7. Set a reminder for two weeks out to check impressions before deciding what to repeat.

    The post is not finished when it is published. It is finished when the same idea has met five different readers in the five places they already spend time, and none of them had to be told it was the same idea.

  • How to Write a Blog Post in 90 Minutes

    How to Write a Blog Post in 90 Minutes

    A blog post takes me 90 minutes from blank page to published. The trick is not typing speed — it is doing one job at a time instead of all four at once. Research, outline, draft and edit each need a different kind of attention, and every switch between them costs you the thread you were holding. Ninety minutes is enough for a 900 to 1,200 word post that answers one question properly. It is not enough for a guide that tries to answer ten.

    The short version

    • Five blocks: 15 minutes research, 10 outline, 35 draft, 20 edit, 10 publish.
    • Research ends when the timer ends — three sources, then start writing.
    • The outline is a list of questions a reader would ask, not a list of headings.
    • The first draft is allowed to be bad. Fixing it is a separate job done later.
    • Editing is three passes in a fixed order: structure, sentences, facts.

    The five blocks, with the one rule that keeps each one from eating the next:

    Block Minutes The job The rule
    0:00 – 0:15 15 Collect what one question needs Three sources, then stop
    0:15 – 0:25 10 Turn the question into sub-questions If you cannot answer it in one line, cut it
    0:25 – 1:00 35 Write the whole thing, badly No editing, no new research
    1:00 – 1:20 20 Structure, sentences, facts Three passes, in that order
    1:20 – 1:30 10 Image, links, slug, live check Done beats perfect

    Minutes 0–15: research with a stop rule

    Open a scratch document and write the post’s question the way a reader would type it into a search box. Not “content marketing tips” — “how long should a blog post be before people stop reading”. One question. If you cannot get it down to one, you are about to write two posts badly instead of one post well.

    Then collect three things and nothing else:

    • What you already know from doing the work. For a migration post, that is the step order and the one step you always forget.
    • One authoritative source — the official documentation, the changelog, the pricing page. Copy the exact sentence and the URL into your scratch document so you never have to find it twice.
    • One real example: a screenshot you took, a command output, a before-and-after you can describe from memory.

    If a fact is missing when the timer rings, do not go looking for it. Type a placeholder — [CHECK VERSION] — and keep moving; you will verify it in the edit block or cut the sentence. Research is where time disappears, because every tab feels useful and usually is not. The post needs three things, and you already have two.

    Minutes 15–25: turn the outline into questions

    Most outlines are a list of nouns: “Introduction, Why it matters, Best practices, Conclusion.” That produces a post that says nothing, because “Best practices” does not tell you what to write underneath it. Replace each heading with the question a reader would actually ask, then write the one-line answer. If there is no one-line answer, you have found the section that will take an hour — cut it or split it into its own post.

    This is the outline I type, every time:

    TITLE (the reader's question, in their words)

1. What do I need before I start?
   -> one line:

2. What does it look like when it is done?
   -> one line:

3. What goes wrong, and what do I do about it?
   -> one line:

4. What is the checklist?
   -> one line:

STILL OWED: [ ] screenshot  [ ] version number  [ ] link

    Four questions is a 900-word post; six is about 1,200. More than that is a series, and it will read like a list of everything you know instead of an answer to the title.

    Minutes 25–60: draft straight through

    The draft block has one rule: do not stop to fix anything. Not the sentence you just wrote, not the fact you are unsure of, not the comma you can feel is wrong. Every stop is a context switch, and the switch back costs more than the fix saved.

    Practical version of that rule:

    • Write the opening as three blunt sentences that answer the question, then leave it alone until the edit block. Do not polish it now, and do not write a warm-up paragraph first.
    • Fill in each outline question with paragraphs. When a paragraph is not working, type the sentence you are trying to say in capitals and move to the next one.
    • No new research. If you need a fact you did not collect, write a placeholder.
    • No formatting, no image hunting, no plugin fiddling. Those belong to the publish block.

    A thousand words in 35 minutes is under thirty words a minute — slower than you type. The time goes into deciding what the next sentence says, which is the actual work.

    Minutes 60–80: edit in three passes

    One long read-through finds typos and nothing else, because you cannot judge structure and commas at the same time. Three short passes, in this order:

    Pass one, structure. Read only the subheadings and the first sentence under each one. Does the post answer the question in the title? Is any section saying the same thing as the one above it? Cut it, even if you like it. Move the strongest section to the top.

    Pass two, sentences. Read each paragraph once, out loud in your head. Split anything over about thirty words. Delete the phrases that only exist to fill space — “in today’s fast-paced world”, “it is important to note that”, “let’s dive in”.

    Pass three, facts. Every number, date, product name and version gets checked against the source you saved, or deleted. This is where credibility is decided, and it is the pass people skip when they are running late. If you cannot verify a claim, say plainly that you have not tested it. A shorter post with true sentences is worth more than a long one with one invented figure.

    Minutes 80–90: publish, then stop

    The publish block is mechanical, so it gets ten minutes:

    • Slug: the question, shortened, words separated by hyphens. Set it before you publish — I cover the permalink settings in the WordPress settings I change on every new site.
    • Image: resize it before upload, and write alt text that describes what is in the picture rather than repeating the title. Oversized uploads are one of the reasons WordPress sites end up slow.
    • Internal links: two or three, each pointing at a post that answers the reader’s next question. Click every one before publishing.
    • Excerpt or meta description: two sentences that answer the question again, in different words from the title.
    • Check: open the live URL. Does it load, does the title match, does the image appear, does the page fit a phone screen?

    Then stop. The temptation is to keep tweaking, and that is how a 90-minute post becomes an afternoon. Tomorrow’s post is the next thing, not this one.

    Where the 90 minutes actually goes wrong

    Four failures account for almost all of it. Research expands to fill the time available, so set an alarm. Editing starts during the draft, so the draft never gets finished. The outline is written as nouns instead of questions, so the writing block has nothing to aim at. And the post tries to be comprehensive, when comprehensive is three posts and the reader came for one answer.

    One honest exception: a post that depends on data you must gather — dashboard screenshots, a test to run, numbers to collect — is not a 90-minute post. Give it three hours or split it; forcing it into the block means publishing half the evidence.

    Start smaller than it sounds: take the question people ask you most, set a timer for 15 minutes, and do only the research block. When it rings, write the four questions and stop if you want. And if you are choosing what to write next, the fastest source of real questions is the Performance report in Google Search Console: the queries your pages already appear for are the questions you are closest to answering well.

  • How to Set Up Google Search Console Properly

    How to Set Up Google Search Console Properly

    Search Console is the only place Google tells you what it actually did with your site — which pages it indexed, which queries showed you, and whether a human reviewer took action against you. The setup that matters is short: one Domain property verified by DNS, one sitemap submitted, alerts going to an address you read, and a ten-minute check once a week. Everything else in the interface can wait until you have traffic worth analysing.

    The short version

    • Create a Domain property, not a URL-prefix property. One property covers http, https, www and every subdomain you own.
    • Verify with a DNS TXT record and leave the record in place. Google re-checks it, and deleting it costs you access.
    • Submit the sitemap WordPress actually generates — /wp-sitemap.xml on a stock install, /sitemap_index.xml with Yoast or Rank Math.
    • Three reports are worth opening: Performance, Page Indexing, and Security & Manual Actions.
    • Data lags a couple of days and new pages take weeks to be crawled. Check weekly, not hourly.

    Pick the Domain property, not the URL prefix

    Google offers two kinds of property. A URL-prefix property is tied to exactly one protocol, one hostname and one path: https://example.com does not include https://www.example.com, and neither includes http://. A Domain property covers all of them, plus every subdomain, because ownership is proved at the DNS level for the bare domain.

    Property type Covers Choose it when
    Domain Every protocol and subdomain: example.com, www., shop., http and https You control the DNS, which is the normal case for a site you own
    URL prefix One scheme, host and path, exactly as typed You cannot edit DNS, or you are monitoring a section of a domain you do not own

    In the add-property screen, choose Domain, type the bare domain without https:// and without a trailing slash, and continue. Do not also create a URL-prefix property “just in case”: the two keep separate data and separate emails, so you end up watching two half-empty dashboards instead of one complete one.

    If your DNS lives at Cloudflare, the record goes in the same place as everything else — the Cloudflare setup walkthrough covers the settings that break sites.

    Verify with a DNS record and leave it alone

    Google gives you a TXT value that looks like this. Copy it exactly, including the google-site-verification= prefix.

    Type:  TXT
Name:  @            (the bare domain)
Value: google-site-verification=AbC123dEf456...
TTL:   Auto or 3600

    In cPanel that is Zone Editor → Manage → Add Record → TXT. In Cloudflare it is DNS → Records → Add record, type TXT, name @. Save, wait a few minutes, then press Verify back in Search Console. When verification fails it is almost always one of three things: the record went on www instead of the root, the value was pasted with a smart quote or a line break from an email, or the DNS change has not propagated yet. Give it an hour before you start changing things.

    The mistake I see most often is cleanup. Six months later someone tidies the DNS zone, deletes the “random TXT record”, and the property breaks. Google re-checks ownership periodically; when the record is gone, access goes with it. If you move nameservers, recreate the TXT record at the new provider before you flip the delegation.

    The HTML-tag and Google Analytics verification methods are fine, but both are fragile in WordPress: a theme change can strip the tag from the header, and a plugin that removes the analytics snippet takes the property with it. DNS survives theme updates, plugin audits and migrations, which is why it is the one I use.

    Submit the sitemap WordPress already builds

    You do not need a sitemap plugin to start. Since WordPress 5.5 there is a built-in sitemap at /wp-sitemap.xml; if you run Yoast or Rank Math it is /sitemap_index.xml instead. Open the URL in a browser first — you should see XML, not a 404 and not a redirect to the homepage.

    Then go to Indexing → Sitemaps, paste the full URL, and submit. The status column should read Success within a day or two. Couldn’t fetch usually means the URL redirects, robots.txt blocks it, or the response is HTML; fix that before submitting again, because repeated failures do not speed anything up.

    Two more things worth doing once: add a Sitemap: line to robots.txt pointing at the same file, and open the sitemap index itself. A stock WordPress sitemap splits into posts, pages, categories and users, and if one of those child sitemaps errors the parent reports it as a warning. A sitemap is a hint, not a command: it tells Google where the URLs are and nothing more. Submitting the same file every day does not push a page into the index.

    Read three reports and ignore the rest

    Performance is the report people open first and the one most often misread. It shows queries, pages, countries and devices for a chosen date range, three months by default. Two cautions: the data lags by a couple of days, so yesterday always looks like a cliff, and “average position” is an average across every impression, not the position you see when you search from your own desk. Filter by page to see which queries actually feed one article.

    Page Indexing is the honest one. It lists every URL Google knows about and why it is or is not indexed. The reasons are not equally urgent:

    • Discovered – currently not indexed: Google knows the URL exists and has not crawled it yet. On a small site this is often just queue time. Internal links from pages that are already indexed help more than anything else.
    • Crawled – currently not indexed: Google fetched the page and chose not to keep it. That is usually thin or near-duplicate content. Improve the page instead of requesting indexing every morning.
    • Excluded by noindex: a setting, not a bug. Check the page source for the tag, then find the plugin or theme option that adds it.
    • Alternate page with proper canonical tag: normal on paginated and tagged archives. Not an error.
    • Duplicate, Google chose a different canonical: look at your canonical tags; on WordPress the usual culprits are archives and query strings.

    Security & Manual Actions holds two sections that look similar and mean different things. A manual action is a person at Google deciding your site breaks the spam policies; a security issue is Google believing your site is hacked or serving malware. Both are emailed to verified owners and both are urgent. If either list is not empty, stop reading about search optimisation and deal with it — the five-minute infection check is the fastest first pass, and the recovery walkthrough is the order I would work in.

    The weekly ten-minute check

    Search Console emails you about manual actions and security issues. It will not email you when a page quietly drops out of the index, so put a recurring slot in the calendar and work through the same five items:

    1. Page Indexing — did the “not indexed” count jump by more than a few pages? Open the reasons and look for a new one.
    2. Performance — compare the last 28 days with the previous 28. Find one query or page that lost clicks and write down why.
    3. Security & Manual Actions — confirm both sections are empty.
    4. Sitemaps — status Success, with a recent “last read” date.
    5. Settings → Users and permissions — once a quarter is enough; remove accounts you no longer control.

    That is the whole routine. The reason to keep it boring is that the signals that matter — a page dropping out of the index, a query collapsing, a manual action — are visible within a week if you look, and invisible for months if you do not.

    If you only do one thing this week: create the Domain property, paste the TXT record at your DNS provider, submit /wp-sitemap.xml, and put the ten-minute check on your calendar. Then go back to writing. Search Console rewards patience far more than it rewards fiddling, and once the property is verified and the sitemap is in, the only thing left to improve is the site itself.

  • Email Deliverability Basics for Small Sites: SPF, DKIM, DMARC

    Email Deliverability Basics for Small Sites: SPF, DKIM, DMARC

    Three DNS records decide whether your email reaches the inbox: SPF lists the servers allowed to send as your domain, DKIM signs every message so the receiver can tell it was not altered on the way, and DMARC tells the receiver what to do when either check fails. Get one wrong and small sites do not see an error — invoices, password resets and replies just land in spam or vanish. Here is the whole setup, in the order I do it.

    The short version

    • SPF is one TXT record per domain listing the servers allowed to send. Two SPF records is not redundancy, it is a broken domain.
    • DKIM needs a private key on the mail server and a public key in DNS at selector._domainkey.yourdomain. A DNS row without a signing server is decoration.
    • DMARC is a TXT record at _dmarc that ties the From address to SPF and DKIM and sets a policy. Start at p=none, read the reports, then tighten.
    • Test by sending to a real Gmail address and reading the headers, not a checker that only reads DNS.
    • If WordPress sends through PHP mail(), fix that before touching DNS. Hosting IPs are the ones receivers distrust.

    What each record actually does

    They fail separately. SPF reads the envelope sender — the Return-Path, which your customer never sees. DKIM reads a cryptographic signature over the headers and body. DMARC reads the From header your customer does see, and asks whether SPF or DKIM passed for that domain.

    Record Lives at What it proves Usual mistake
    SPF (TXT) @ Which servers may send as you Two SPF records, or over ten lookups
    DKIM (TXT) selector._domainkey The message was signed by your key Key in DNS, server never signs
    DMARC (TXT) _dmarc What to do on failure, and where reports go p=reject before anything was verified

    Where the records go, and what is live now

    The records belong in the DNS zone, where the A record lives. In cPanel that is Zone Editor; in Cloudflare it is DNS → Records → Add record, type TXT, TTL Auto. If your nameservers sit at the registrar while the site sits on hosting, the mail records still go at the registrar: email DNS follows the nameservers, not the web server. On Cloudflare, mail records must be DNS only, never proxied — the same rule as in the Cloudflare setup guide.

    Look at what is published before you change anything:

    # SPF
dig +short TXT example.com | grep -i spf

# DKIM — use the selector your provider gives you
dig +short TXT default._domainkey.example.com

# DMARC
dig +short TXT _dmarc.example.com

# Windows, no dig:
nslookup -type=TXT example.com

    Two lines of v=spf1 means the record exists twice — worse than missing.

    SPF: one record, ten lookups, and the ending that matters

    An SPF record lists who may send, plus a qualifier for everyone else. For a site sending from its own hosting and one outside provider:

    v=spf1 a mx include:_spf.provider.example ip4:203.0.113.10 -all

    Read it left to right: a allows the server behind your A record, mx your incoming mail hosts, each include: another domain’s SPF list, ip4: a single address. Replace the example IP with yours.

    Two rules break more SPF records than anything else. First: one SPF record per domain name. If your host adds one and a marketing tool tells you to add another, merge them into a single line. Second: the ten-lookup limit in the SPF specification. Every include, a, mx, ptr and exists counts toward it, and going over returns a permanent error that receivers read as “no valid SPF”. MXToolbox and dmarcian both report the lookup count; check it before adding another include.

    End with -all once you are confident, ~all while you are still finding senders you forgot. Soft fail is a test mode; it protects nothing.

    DKIM: the key has to exist on the server

    DKIM is the record people copy correctly and still get wrong, because the DNS entry is only half of it. The public key goes in DNS; the private key stays on the machine that sends your mail, and that machine must be configured to sign. Publish the record without enabling signing and every message fails DKIM while you edit DNS for nothing.

    The right order: enable DKIM in your hosting panel first — in cPanel it is Email Deliverability — then copy the exact record it generates. Do not generate your own key pair and hope the panel picks it up. The selector is part of the record name and your provider chooses it; default, mail and google are common.

    If your DNS host splits a long TXT value into quoted chunks, that is normal; resolvers join them again. Breaking the value yourself is not.

    DMARC: monitor first, enforce later

    DMARC is the policy layer. Start with this:

    v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100

    p=none means “deliver as normal, just tell me what happened”. It protects nothing by itself, and that is exactly why it is the right first step: your reports will show every legitimate sender you forgot, including the contact form on your own site. Point rua at a mailbox you actually read, or at a reporting service — the reports arrive as XML and nobody reads them by hand.

    After a few weeks of clean reports, move to p=quarantine and then p=reject, in steps with pct if you send volume. Alignment matters more than it looks: DMARC passes only if SPF or DKIM passes and the domain in that result matches the From domain. A host that sends as yourdomain.com but authenticates as its own domain passes SPF and still fails DMARC — the most common cause of “all my records are green but DMARC fails”.

    Test from a real mailbox, then fix the sending path

    Send a message from the site’s contact form and one from webmail to a Gmail address you own. Open it, use the three-dot menu, choose Show original, and read the authentication results near the top. You want three passes: SPF, DKIM with your selector, DMARC. Send the same message to an Outlook address too — Microsoft’s filters weigh reputation differently and will catch a problem Gmail forgives.

    If SPF passes and DKIM fails, the server is not signing or the selector does not match. If both pass and the mail still lands in spam, the problem is reputation, not authentication: a domain that has never sent mail looks exactly like a spammer’s first domain. Send consistently, keep volume modest at the start, and make sure every message is one somebody asked for.

    The WordPress part trips up more small sites than DNS does. PHP mail() sends from the web server’s IP, shared with every other site on that host — and that is the reputation your mail inherits. Configure SMTP to your real mailbox or a transactional provider (WP Mail SMTP and Post SMTP both do it), and check that outbound port 25 is not blocked, which many VPS providers do by default; port 587 exists for that reason. If the host’s IP reputation is the problem, no DNS record saves you, which is worth weighing when you compare cheap hosting against good hosting.

    Forwarding is the last trap: a forwarder re-sends with a new envelope sender, so SPF fails at the destination while DKIM usually survives. And when you change hosts, do not touch MX and SPF in the same hour — the migration checklist covers the sequencing so mail does not bounce.

    The checklist before I call it done

    • Exactly one SPF record, ending in -all, under ten lookups, covering every tool that sends for you.
    • DKIM signing enabled on the server, selector in DNS matching the signature, confirmed by a real message.
    • DMARC at _dmarc with p=none and a rua mailbox someone reads.
    • Test messages to Gmail and Outlook, all three checks passing in the headers.
    • WordPress sending over SMTP on port 587, not PHP mail().
    • Reverse DNS set for the sending IP if you run your own server.

    Do it in that order today: SPF, DKIM, DMARC at p=none, then one test message to your own Gmail and read the headers. It tells you more than any dashboard, because it measures what your customer receives.

  • How to Choose a Domain Name You Won’t Regret in 3 Years

    How to Choose a Domain Name You Won’t Regret in 3 Years

    The domain name is the only part of a website you cannot quietly swap later. Hosting, theme, even the platform can change in an afternoon. A domain carries every inbound link, every email address and every mention anyone ever wrote about you. Pick it the way you would pick a business name — slowly, and with year three in mind.

    My rule is simple. A name is safe to buy when it passes three tests: someone can hear it once and type it correctly, the renewal price does not jump after the first year, and no trademark or established business is already sitting on it. Everything else is taste.

    The short version

    • Say it out loud to a real person before you check availability. If they ask you to repeat it, the name is wrong.
    • Take the .com unless you are deliberately local. Local is a strategy, not a consolation prize.
    • Judge the price at renewal, not the first-year promo. That is where registrars earn.
    • Register the domain in your own account, with your own email, separate from your hosting.
    • Run four checks before you pay: trademark, past use, social handles, and who controls the DNS.

    The phone test comes before the availability check

    Most people open a registrar first and start typing names into a search box. That is backwards. The registrar will tell you what is available; it will never tell you what is usable.

    Read the name to someone over the phone, or send it in a voice note. If they ask you to spell it, or read it back wrong, you have your answer before you spend anything. A name that needs a sentence of explanation is a name you will explain for years.

    What I avoid, in the order it usually bites:

    • Doubled letters at the join. Two words that end and start with the same letter merge when spoken.
    • Numbers. “4” or “2” forces a digit-or-word decision on every visitor.
    • Hyphens. People drop them, so assume half your visitors type the unhyphenated version.
    • Plurals and possessives. If the name needs an apostrophe or a final “s”, people will leave it out.

    Two words, three syllables, no explanation. If you can say it in a noisy restaurant and get it typed back correctly, it survives a business card and a customer telling a friend.

    Brand or keyword: decide what the name has to do in three years

    Keyword domains describe what you sell. Something like klplumber24.com tells a stranger exactly what you do and roughly where. That is a real advantage for a local service business that will still be doing the same work later.

    The cost is that the name becomes a ceiling: add a second service, move city, or sell the business, and the name works against you.

    Brandable names — a short invented or semi-invented word — cost you clarity up front and repay it later. You can add services, change cities, launch products under the same roof. My compromise for most small sites: a short brandable root plus a plain-language tagline in the site title.

    One honest exception: if the business is local and service-specific with no ambition to change, the keyword name is the better marketing decision. Buy it knowing it is a permanent label.

    The extension is a trust decision, not a fashion decision

    Use .com when you can get it. Not because it ranks better, but because it is the default in people’s heads. When someone half-remembers your name, they type .com first.

    Country extensions — .com.my here in Malaysia, .co.uk, .com.au — buy local credibility. If your customers are all in one country and you compete with local businesses, that signal is worth the extra cost and the registration rules.

    New generic extensions are fine and often cheap, but they carry a spelling tax and a trust question. Some corporate mail filters treat unfamiliar extensions with suspicion. I use them for campaign sites, not for the address that goes on the invoice.

    The renewal price is the real price

    Registrars advertise the first year and earn on the rest. Before you check out, find the renewal price for the same domain and multiply it by three. If the promo year is cheap and the renewal is not, you have not found a bargain — you have found a discount on the least important year. It is the same trick as cheap hosting that looks fine until you read the fine print.

    Cost line What to check What it costs if you skip it
    Renewal price The price in year two, not the promo A bill you did not budget for, every year
    Transfer and redemption Cost to move out, cost to recover a lapse Redemption fees are punitive by design
    Privacy and email Is WHOIS privacy included or an upsell? Your home address in a public database

    The redemption line matters more than it looks. Let a domain expire and you do not simply re-buy it at the normal price — you pay a recovery fee, and sometimes you lose the name to an auction while you decide. Which is why auto-renew and a card on file are part of the purchase.

    Four checks before you pay

    This takes about twenty minutes and has saved me from names I would have regretted.

    1. Trademark. Search the national register — MyIPO in Malaysia — and a plain web search for the name plus your industry. You are looking for an existing business in the same field, not for any use of the words anywhere. A trademark dispute is decided by who registered first and in what class, not by who bought the domain first.

    2. Past life. Check the Wayback Machine and search the name. A domain that previously hosted spam, a pharmacy or a link farm carries that history. Search engines remember longer than registrars do, and cleaning it up is slow, uncertain work. A cheap expired domain with backlinks is usually cheap for a reason.

    3. Handles. Look up the same name on the social platforms you will actually use. A name that is free as a domain but taken everywhere else means every profile needs a variant, and you spend years explaining which one is you.

    4. DNS and ownership. Confirm you get full DNS control and that the registrant will be you. If a host or a developer offers to register it “for you”, decline politely. The account holder is the owner in every dispute that matters.

    whois yourname.com | grep -iE "registrar|creation|expiry"
dig +short NS yourname.com
dig +short MX yourname.com

    Read the output, not just the exit status. A creation date from years ago on a name you thought was free means it was dropped and re-registered. Name servers pointed somewhere unexpected mean it was in use recently.

    Register it for the person you will be in three years

    Buy in your own registrar account, using an email address on a different domain. If your only recovery address is the domain that just lapsed, you cannot receive the recovery message. Turn on two-factor authentication too — domain theft happens through registrar logins, not DNS attacks.

    Keep the domain and the hosting in separate accounts, ideally separate companies. When you move a site to a new host, the domain should stay exactly where it is and only the DNS records should change. I keep DNS at Cloudflare and treat the registrar as a billing relationship, so a migration is a nameserver edit rather than a transfer.

    Register for several years when the price is locked, and keep auto-renew on regardless. The renewal is a rounding error next to what losing the name would cost.

    Before you click buy

    • Say the name to one real person. Fix it if they hesitate.
    • Search the trademark register and the name itself.
    • Check the year-two renewal price and the transfer fee.
    • Check the social handles you will actually use.
    • Confirm the registrant will be your own account, with 2FA.
    • Set auto-renew and a calendar reminder thirty days before expiry.

    If you do only one thing from this article: check the renewal price before the first-year price. The name you keep for three years is the one you can afford to keep, and the best time to find that out is before you print it on anything.

  • Anatomy of a Hacked WordPress: What Attackers Leave Behind

    Anatomy of a Hacked WordPress: What Attackers Leave Behind

    When a WordPress site gets hacked, the visible symptom is usually the last thing to arrive. The real footprint is a handful of files, a couple of database rows, and one user account you did not create. If you know the six places to look, you can tell a hacked site from a broken one in about ten minutes — and you can do it without installing a security plugin.

    Clean up a few of these and the pattern repeats: the same four directories, the same three tables, the same two persistence tricks. Attackers reuse what already works.

    The short version

    • Most infections live in wp-content/plugins, wp-content/mu-plugins, wp-content/uploads, and the active theme’s functions.php.
    • mu-plugins is the favourite hiding place: files there load automatically and never appear in the Plugins screen.
    • Core files usually get one or two lines changed, so run wp core verify-checksums before you trust anything else on the site.
    • Check users and cron next. A rogue administrator or a scheduled event calling an outside URL is persistence, not just a symptom.
    • Cleaning files without finding the entry point means you will be back here in three weeks.

    Start with the file system, not the scanner

    A scanner matches signatures; a hand-edited theme file that includes a remote script usually passes. These three structural checks are faster and do not depend on a signature database being current.

    Run them from the WordPress root over SSH, or through your host’s file manager terminal.

    # PHP files inside uploads — there should be none
find wp-content/uploads -type f -name '*.php'

# Everything modified in the last 30 days, newest last
find wp-content -type f -name '*.php' -mtime -30 -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort

# Any PHP file that is world-writable, a common attacker trick
find . -type f -name '*.php' -perm -o+w

    The first command should print nothing. Uploads is for images and documents; a .php file sitting next to your photos was put there by someone, and it is a backdoor.

    The second command is a timeline: compare it with the dates you actually ran an update.

    mu-plugins: the folder that loads and hides

    This is the trick I see most often, and the one most site owners have never heard of. Anything in wp-content/mu-plugins loads on every request with no activation step and no entry in the Plugins list. Good hosts use it for a cache loader or an object-cache drop-in. Attackers use it for a single line of PHP.

    ls -la wp-content/mu-plugins/

    If you do not recognise a filename, read the first twenty lines. A real mu-plugin has a comment header and actual code. A malicious one is often a lone include of a file elsewhere, or one very long base64 string passed to eval, gzinflate or create_function. There is no legitimate reason for a plugin to decode a string and execute it.

    Do not just delete the file. Note its name and look for the same string in the theme and in wp-config.php — a mu-plugin loader is usually called from two or three places so that removing one copy does nothing.

    Fake plugins with real-looking headers

    A dropped plugin differs from a real one in ways that survive a quick glance. It has a proper header block — Plugin Name, Version, Author — because that header is what makes the file a plugin at all. What it lacks is history: no changelog, no readme in the format WordPress expects, and an author URL on a recently registered domain.

    wp plugin list --fields=name,status,version,update
ls -la wp-content/plugins/

    Compare the two: the command lists what WordPress knows about, the directory shows what is on disk. A folder with no matching row was never installed through the admin — someone dropped it there. A plugin whose files all share one timestamp while the header claims an old version is not one anyone maintained.

    Core files: one line is enough

    Injections into core are small on purpose. A single line at the top of wp-settings.php or index.php, often wrapped in a check for a specific user agent or a cookie, is enough to serve a payload to Googlebot and nothing to you.

    WordPress ships with checksums for every file in every release, and WP-CLI can compare your installation against them:

    wp core verify-checksums

    Clean output means no core file has been edited; warnings name the files that differ. Do not fix it by unpacking a fresh copy over a live site — read the diff first, then replace that one file from the official zip.

    The database footprint: users, options, cron

    Files get you access. The database is what keeps it. Three tables carry almost all of the persistence: wp_users, wp_options, and wp_usermeta with the serialised cron array.

    wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp cron event list --fields=hook,next_run,recurrence
wp option get siteurl
wp option get home

    On the user list, look at the registration date, not the name. Attackers pick names that blend in — wp_support, admin_backup, editor2 — but they appear on a date when you were not working. Every administrator should be a person you can name.

    On the cron list, a hook with no plugin behind it is the tell. WordPress will happily schedule an event pointing at a function that a malicious mu-plugin defined; the event itself looks ordinary. If you cannot trace a hook to a plugin you installed, treat it as hostile.

    For options, siteurl and home should be identical and should be the URL you expect. A mismatch is the classic way to keep an admin logged in on one hostname while sending visitors elsewhere.

    Redirects and injected sitemaps

    Some infections never add a PHP file. They edit .htaccess and add a rule that fires only for mobile user agents, or only for traffic arriving from a search engine. The page looks completely normal to you and redirects every visitor from Google to a casino.

    Read .htaccess from the top. Rules inside <IfModule mod_rewrite.c> that reference HTTP_USER_AGENT, HTTP_REFERER, or a specific country code are not part of WordPress — the stock rules only rewrite to index.php.

    The sitemap is the other quiet channel. Check /sitemap.xml and /wp-sitemap.xml against your post list. URLs you never published mean the injection is generating pages on the fly, usually only for a crawler carrying a Google referrer. That is exactly what happened when my own site was hit with Japanese keyword spam — the recovery steps are here.

    Where to look, at a glance

    Where it hides What you see How to confirm
    uploads a .php file beside images find wp-content/uploads -name '*.php'
    mu-plugins unrecognised file, no Plugins entry ls -la wp-content/mu-plugins/
    plugins folder with no matching wp plugin list row diff the list against the directory
    core one edited line in a core file wp core verify-checksums
    users admin registered on a quiet day wp user list --role=administrator
    cron hook that belongs to no plugin wp cron event list
    .htaccess / sitemap redirects or URLs you never published read the rules, compare sitemap to posts

    Removing files is half the job

    The other half is the entry point: an unupdated plugin, a reused password, or a theme that bundles “nulled” premium code. Locking down wp-login closes the front door; it does not remove a key already copied.

    So after you clean the files: change every administrator password, change the database password, regenerate the WordPress salts in wp-config.php (which invalidates every existing login cookie), and revoke any FTP or SSH key you do not recognise. Then check your hosting account for extra FTP users — a leftover FTP account survives a full WordPress reinstall.

    Be careful with the restore: if the last backup already contained the backdoor, restoring it puts you back where you started. Compare files against a known-good copy, not a snapshot from an infected week.

    Then read the access log for the day the files changed — the request that wrote them is in there, with the IP and the path it used. That is how you find the entry point instead of guessing at it.

    What to do today

    Run the three file-system commands and wp core verify-checksums, and save the output to a file on your own machine. That file is your baseline: next time something feels wrong, run the same commands and compare. Ten minutes now beats an afternoon of wondering.

  • How to Read Your Access Logs and Spot a Brute-Force Attack

    How to Read Your Access Logs and Spot a Brute-Force Attack

    A brute-force run against WordPress looks like the same request to wp-login.php repeating hundreds of times from one address, usually with a scripted user agent and a response that never changes size. You do not need a security plugin to see it. You need the raw access log, three shell commands, and about five minutes.

    I open the access log before any dashboard, because a dashboard tells you what it chose to record and the log tells you what the server received.

    The short version

    • Log fields are positional. Field 1 is the IP, field 7 is the requested path, field 9 is the status code, field 10 is bytes sent.
    • One line means nothing. Two hundred of the same line from one IP inside an hour means everything.
    • POST /wp-login.php returning 200 is a rejected attempt. Returning 302 means somebody got through.
    • Count before you block, and prefer hardening the endpoint over banning the address — botnets rotate IPs faster than you can write firewall rules.
    • Read the rotated files too. Attacks straddle midnight, and the .gz from yesterday holds the half you are missing.

    One line, read left to right

    Apache and nginx both default to the combined log format. Fields are separated by spaces, and the quoted parts can contain spaces of their own, which is why the request is wrapped in quotes as a single unit.

    203.0.113.45 - - [01/Nov/2026:04:12:33 +0800] "POST /wp-login.php HTTP/1.1" 200 4312 "-" "python-requests/2.31.0"

    Read it as a sentence. At 04:12 in the morning, an address that sent no referrer and identified itself as a Python script posted to the login form, and the server answered with a 200 and 4,312 bytes. Nothing about that line belongs to a person.

    Field In the line above Why it matters
    1 203.0.113.45 Who. Group by this first.
    4–5 01/Nov/2026:04:12:33 When. Real customers sleep.
    6–8 POST /wp-login.php What they asked for. Method plus path is the whole story.
    9 200 Result. 200 means rejected, 302 means logged in.
    10 4312 Bytes sent. Hundreds of identical counts means nothing changed.
    12 python-requests/2.31.0 Client. Browsers do not introduce themselves as Python.

    The IP above is from the documentation range, not a live log.

    Where the file actually lives

    This is the step most people give up at.

    cPanel: /home/<user>/access-logs/<domain.com>. It is a symlink to the real domlogs file, and it is readable by your account, which is all you need. The error log sits in ~/logs/. If you are in File Manager rather than SSH, turn on hidden files, because the directory is easy to miss next to the public_html tree.

    Plesk: /var/www/vhosts/system/<domain>/logs/. Inside it you get access_log, access_ssl_log, proxy_access_log and the matching error logs. On Plesk, nginx sits in front of Apache and sees the real client IP, so proxy_access_log is the file you want when access_log shows a loopback address.

    Plain nginx: /var/log/nginx/access.log, with access.log.1 and gzipped archives beside it. Rotated files end in .gz, so read them with zcat instead of cat — a normal attack runs for hours and will be split across two files.

    The four patterns worth naming

    Not every 404 is an attack and not every bot is hostile. These four are the ones I act on.

    1. The login drumbeat. Hundreds of POST /wp-login.php lines from one address, all 200, all roughly the same byte count. The 200 is the point: WordPress re-renders the form with an error, so a rejected attempt and a served form share a status. Identical byte counts are the giveaway.

    2. The 302 that follows. A POST /wp-login.php answered with 302 is a successful authentication — WordPress redirects to /wp-admin/ on success and only returns 200 on failure. If the timestamp is 3 a.m. and the IP is not yours, assume the password is already known to someone else. Rotate it before you do anything else, then run the five-minute infection check.

    3. XML-RPC as an amplifier. POST /xmlrpc.php with system.multicall lets a client try hundreds of passwords in a single HTTP request. It barely registers in request counts and hammers the CPU, which is also how small accounts end up suspended for resource abuse. If you do not publish from a desktop client or the WordPress app, turning XML-RPC off removes the whole class of attack.

    4. Reconnaissance before the attempt. GET /?author=1 through ?author=9 enumerates usernames. So does /wp-json/wp/v2/users. A scattering of 404s against plugin folders you never installed is somebody running a vulnerability scanner against your site. None of it breaks anything by itself; all of it is a preview of what comes next.

    Counting, not squinting

    You cannot eyeball ten thousand lines. Three commands answer almost every question I have. Run them from the directory that holds the log.

    # top talkers, all traffic
awk '{print $1}' access_log | sort | uniq -c | sort -rn | head -20

# who is hitting the login form
grep 'POST /wp-login.php' access_log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# bursts: requests per IP per minute
awk '{print $1, substr($4,2,17)}' access_log | sort | uniq -c | sort -rn | head -20

# did anything actually succeed?
awk '$9 == 302 && /POST \/wp-login\.php/ {print $1, $4}' access_log

    The third command separates a bot from a person. A visitor loads a page, an image, a script, then leaves — a handful of requests in a minute, all different paths. An attacker sends the same path over and over. More than a few dozen requests to one endpoint in one minute is not a customer.

    Save the output before you change anything. Logs rotate on a schedule you did not set, and the evidence you need for a host support ticket disappears with them.

    Blocking it without breaking your own site

    Blocking an IP is the weakest option and the one most people reach for first. A credential-stuffing run comes from hundreds of addresses; you can ban them one at a time until you run out of patience. Do the durable things first.

    • Rate limit the endpoint at the edge. One rule in Cloudflare — more than a handful of POSTs to your login path per minute from one IP, block for an hour — stops the drumbeat before it reaches PHP.
    • Two-factor authentication on every administrator. It converts a successful password guess into a failed login, which is the only fix that survives a leaked password.
    • fail2ban on a VPS. A jail watching the Apache or nginx access log for repeated 200s on wp-login.php will ban automatically and expire the ban on its own.
    • .htaccess as a last resort. If you must deny an address by hand, wrap the rule so you do not wipe out normal access, and whitelist yourself first.
    <RequireAll>
    Require all granted
    Require not ip 203.0.113.45
</RequireAll>

    On cPanel, the IP Deny Manager does the same thing with a form. Either way, add your own address and your uptime monitor to the allow list before you add anything to the deny list, or you will lock yourself out of the admin you were trying to protect. If the log already shows a 302, the ban is housekeeping — change the password, check for new administrator accounts, and treat the site as compromised until you have looked.

    Ten minutes, the next time you get an alert

    1. Open the access log, not the dashboard.
    2. Run the top-talkers command and look for one address far ahead of the rest.
    3. Grep the login path and count per IP.
    4. Check for any 302 on a login POST. If it exists, rotate the password now.
    5. Check POST /xmlrpc.php traffic and disable XML-RPC if you do not use it.
    6. Look for ?author= sweeps and /wp-json/wp/v2/users requests.
    7. Read yesterday’s .gz log for the same address.
    8. Only then add a block, and only after you have hardened the endpoint.

    Do one thing today: run the top-talkers command on your busiest site and write the normal number down. You cannot recognise abnormal traffic until you have seen a quiet day. For the logs that matter when something breaks rather than attacks, this is the map I use.

  • What to Do When Your Host Suspends Your Account

    What to Do When Your Host Suspends Your Account

    Your host suspended the account. The email gives you a sentence or two, no evidence, and a ticket you have to answer — and the site is offline right now. In almost every case the trigger is one of four things: malware in your files, a resource limit you crossed, an abuse complaint, or a billing failure. The first hour is not about fixing the site; it is about working out which of those four it is, so you can reply with facts instead of apologies.

    The short version

    • Get the actual reason in writing. “Terms of service violation” is not a reason, and you cannot fix what you cannot name.
    • Take a full backup before you change anything — files and database. Some hosts restore from their own copy, some do not.
    • Look for the cause in your own logs while the account is still suspended. File access usually survives even when the site does not.
    • Reply with what you found, what you changed, and when it is safe to review. Then ask for the exact condition that lifts the suspension.
    • Keep a migration path ready: a short DNS TTL and an off-site backup are what turn a suspension into an afternoon instead of a week.

    First, work out which suspension you are in

    The wording in the email matters more than the tone. Hosts send roughly the same four messages, and each one needs a different answer. If you reply with a general “sorry, I have fixed it” you will usually get a general “we are still reviewing it” back.

    What the email says What it usually means What you check first
    Malware, phishing, or “harmful content” An injected file, a spam page, or a redirect in your theme Files changed recently in wp-content, unknown admin users, core file checksums
    CPU, memory, or entry processes exceeded A plugin, bot traffic, or a cron job running wild Top IPs and top URLs in the access log, resource graph in the panel
    Abuse report or spam complaint A contact form or mailbox being used to send mail from your domain Mail queue, outbound mail logs, form plugins with no captcha
    Invoice overdue or payment failed Purely billing, nothing technical Invoice status and the card on file — pay it, then ask about a grace period

    If the panel still lets you log in, do it now and read the resource graph before anything else. A suspension that arrives at 02:00 with a CPU line in the email is almost always traffic or a cron job, not a person attacking you.

    Collect the evidence before you reply

    Most suspensions still leave you with file access through the panel’s file manager or over FTP. That is enough to find the cause. The access log is the fastest place to look, and on cPanel it usually sits in ~/logs or /home/<user>/access-logs; on Plesk it is under /var/www/vhosts/<domain>/logs. If you have never opened it, the mechanics are the same ones I covered in the article on HTTP 500 and which log tells you why.

    # which IPs are hitting you hardest
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10

# which URLs they are hitting (wp-login.php is the usual suspect)
awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -10

# files changed in the last 7 days
find wp-content -type f -mtime -7 | head -40

    Three patterns cover most cases. One IP with thousands of requests is a bot or a scraper and you can block it at the firewall. Thousands of requests spread over hundreds of IPs hitting wp-login.php or xmlrpc.php is a distributed brute-force attempt, and the host may suspend you just to stop the load. Heavy requests to a single PHP file that is not part of WordPress is usually malware. If the files look wrong rather than the traffic, run the checks in my five-minute infection check and screenshot the results — hosts accept evidence.

    Stop the bleeding without making it worse

    The instinct is to reinstall everything at once. Do not. You cannot tell the host what you fixed if you have replaced half the site, and you cannot compare anything against a clean state. Work in this order instead:

    • Rename, don’t delete. Move the suspected plugin folder to wp-content/plugins-disabled/ so the site stops loading it but you can put it back. Deleting means you cannot inspect it later.
    • Kill the cron. A runaway scheduled task keeps firing even while the site is suspended, which is how a “temporary” suspension turns into a repeat one. Disable WP-Cron in wp-config.php until you are restored.
    • Close the front door. Block the offending IP range in .htaccess or the panel firewall, and disable XML-RPC if you do not use it.
    • Leave the database alone. Dropping tables or removing users during a review removes the evidence the host may ask for.

    Reply like an engineer, not a defendant

    A reply that gets an account restored quickly reads like a short incident report. Six lines, no paragraphs of apology:

    1. What happened, with the timestamp and the log evidence you found.
    2. What caused it, in one sentence — a plugin, a botnet, an outdated theme file.
    3. What you changed, listing the exact files or settings you touched.
    4. How you verified it, such as the log now showing no requests from that range.
    5. What stops it recurring, such as a firewall rule and a patched plugin.
    6. The direct question: what is the specific condition for lifting the suspension, and can they confirm when they will review it.

    Ask for the threshold too. If the suspension was for CPU or entry processes, you need to know the number you exceeded or you will cross it again next month. If the host cannot tell you, that is itself useful information about whether to stay.

    If they will not restore it, move — in the right order

    Some hosts suspend first and investigate later, and a few never give you a clear answer. You can still move, but the order matters. Download a full backup of files and database from the panel before the account is terminated; after termination it may be gone. Lower the DNS TTL to 300 seconds and wait for the old value to expire. Restore on the new host, test it by pointing your own machine at the new IP with the hosts file, and only then switch the nameservers. That is the same sequence as moving a site without downtime, minus the luxury of planning ahead.

    The first hour, in order

    1. Read the email and classify the suspension: malware, resources, abuse, or billing.
    2. Log into the panel if you still can; download a full backup to your own machine.
    3. Pull the access log and find the top IPs and top URLs.
    4. List files modified in the last seven days and check for unknown admin users.
    5. Rename the offending plugin or block the offending range; disable WP-Cron.
    6. Reply with the six-line incident report and one direct question.
    7. Lower DNS TTL now, even if you expect to stay.
    8. Write down what you changed and when — you will need it in the next ticket.

    None of this needs a hosting company’s permission, and most of it takes less than an hour. The one thing worth doing before you ever need it: keep a recent off-site backup and a TTL short enough that a move is measured in minutes. If you have neither, fix that today — because the next suspension email will not arrive at a convenient time. Open the ticket and write three lines: what you found, what you changed, and when it is safe to review. That single reply does more for you than a week of apologising.

  • Why Your WordPress Site Is Slow (and What Actually Fixes It)

    Why Your WordPress Site Is Slow (and What Actually Fixes It)

    Your WordPress site is slow because one layer is doing the damage, and you probably have not found which one yet. The speed fixes people reach for first — an image plugin, a caching plugin, a theme swap — often target a layer that is not the problem. Measure, fix the slowest layer, change one thing, re-measure.

    I run two sites on shared hosting and one on a VPS. The most useful thing I have learned is that a single number tells you which half of the problem to look at.

    The short version

    • Measure time to first byte before you install anything. It is the one number that separates server-side slowness from front-end weight.
    • If TTFB is over a second on a page that is already cached, the problem is hosting, PHP or the database. No front-end trick will fix it.
    • Page caching is the biggest cheap win — and the reason a site can be fast for visitors and slow for you.
    • Images are usually why a page is heavy, not why it is slow to start.
    • Change one thing, re-measure, then change the next. Two at once and you learn nothing.

    Measure first, with one command

    TTFB is how long your server takes to start answering. Run this three times against your homepage:

    curl -o /dev/null -s -w "ttfb=%{time_starttransfer}s total=%{time_total}s\n" https://yourdomain.com/

    On shared hosting, a cached page should answer in well under a second. A figure above 1.5 seconds on a page that is already cached means the server is struggling. Then run the same command against a static file on the same host. If the static file is fast and the homepage is slow, WordPress is doing the work. If both are slow, it is the server or the network, and the rest of this article can wait.

    Two conditions: log out first, because your own admin session bypasses page caching and will always look slower; and test from elsewhere, since your ISP’s route to the host is not your visitor’s route. How to test your hosting speed properly covers that part.

    Layer one: hosting and PHP

    If TTFB is high on a cached page, this is where the time is going.

    Check the PHP version first: Tools → Site Health → Info → Server. Anything on PHP 7.4 or older is both unsupported and slower than 8.x, and changing it is a dropdown in most control panels. Test on a staging copy if you have one, since an old plugin can break on the newer branch — but that move is worth the risk on its own.

    Then look at what your plan actually allows. Shared hosting limits CPU seconds, memory and disk I/O, and when you cross a limit the host throttles you instead of showing an error. A site that is fine at 9am and crawling at 3pm is usually being throttled, not attacked. Check for resource-limit emails and a CPU usage graph in the panel — cheap hosting versus good hosting is about what those limits mean in practice.

    If PHP and the limits look sane, ask support two things: whether OPcache is on, and whether the database is local.

    Layer two: page caching

    A page cache stores the finished HTML so PHP does not rebuild it for every visitor. Done once and properly, it removes most of the load. Done three times, it causes bugs.

    • Use one layer. If your host has a built-in cache — LiteSpeed hosts, most managed WordPress plans — turn it on and skip the plugin. Stacking a host cache, a plugin cache and Cloudflare’s HTML cache is how people end up with stale pages and random logouts.
    • Exclude what has to stay dynamic: /wp-admin, /wp-login.php, and any cart or checkout page. A rule that bypasses the cache when the logged-in cookie is present is what keeps the admin usable.
    • Expect asymmetry. A cached site is fast for visitors and still slow for you while logged in. That is the cache working, not failing.
    • Clear it after every change, or you will spend an hour debugging a fix that is already live.

    If Cloudflare sits in front of the site, its default static-file cache is the safe setting for WordPress — setting up Cloudflare without breaking a small site covers where that line is.

    Layer three: images and front-end weight

    Images rarely cause a slow TTFB, but they cause most of the wait after the first byte and they are the easiest layer to fix.

    Open the homepage and check total page weight and the largest image. A hero exported at 4000 pixels wide for a slot that renders at 1200 is the most common problem I find on small sites. Resize to the size the theme actually displays and export as WebP or AVIF.

    WordPress adds loading="lazy" to images by default since 5.5, which is right everywhere except the image at the top of the page. That one should load immediately — delaying it makes the page feel slower even when the measured numbers improve. Most optimisation plugins let you exclude the first image.

    Then fonts and scripts. Every web font is a separate download that blocks text from painting, so two families with four weights is four files before any content appears. If the theme loads a font you cannot see on the page, remove it. Render-blocking CSS and JS are the other half, and the honest fix is usually fewer plugins.

    Layer four: plugins and the database

    Every active plugin is code that runs on every request, whether or not the page uses it. The reliable way to find the expensive ones:

    • Install Query Monitor on a staging copy and open a normal page. It shows the query count, the slowest queries and which plugin caused each one.
    • Deactivate plugins in halves on staging, measuring TTFB after each round. You will find the culprit in a few rounds without taking the live site down.

    On the database side, the measurement worth taking is autoloaded options — the rows WordPress loads on every single request. In phpMyAdmin:

    SELECT SUM(LENGTH(option_value)) AS autoload_bytes
FROM wp_options WHERE autoload = 'yes';

    A few hundred kilobytes is normal. If that number is measured in megabytes, a plugin is stuffing data into the options table and every page load pays for it. Expired transients are the usual offender. Clearing expired transients is safe; deleting rows you do not recognise is not.

    Last piece of this layer: WP-Cron. It is triggered by page loads, so on a low-traffic site jobs run late, or several at once on the first visit after a quiet spell — exactly when a visitor notices. A real system cron job on the host is a two-line change.

    Symptom, layer, first thing to try

    What you see Layer Do this first
    Fast for visitors, slow for me Page cache Log out and re-test — nothing is broken
    Slow at all hours, static files fast PHP and plugins Move to PHP 8.x, then audit plugins
    Slow only at busy times Host throttling Check resource-limit emails and CPU graph
    Quick start, page still drags Front-end weight Resize the hero image, cut one font
    Random multi-second stalls Cron or an external call Query Monitor, then a real system cron

    The order I actually work in

    Speed work goes wrong when it starts at the bottom of this list. Top to bottom, stopping at the first real improvement:

    1. Measure TTFB, logged out, three times, and against a static file as a control.
    2. PHP version and host limits — cheapest possible fix, biggest possible jump.
    3. One page cache, with the admin and login paths excluded.
    4. Images and fonts — dimensions before compression, and never lazy-load the top image.
    5. Plugin audit on staging with Query Monitor in hand.
    6. Database hygiene — autoloaded options, expired transients, a real cron.

    Now the part that saves the most time: write the before number down. Every change feels faster, especially one you spent an hour on. A number on a note is the only thing that tells you whether the caching plugin did anything at all.

    Today, do one thing: run that curl command against your homepage three times, logged out, and write the three TTFB numbers down. Under a second, and your next hour belongs to images and fonts. Over one and a half seconds on a cached page, and it belongs to hosting and PHP — no plugin in the directory will change that.

  • How to Set Up Cloudflare for a Small Site Without Breaking It

    How to Set Up Cloudflare for a Small Site Without Breaking It

    The Cloudflare setup itself takes about ten minutes. What takes a small site down is almost never Cloudflare — it is one of three settings changed in the hours after the nameserver switch: SSL mode left on Flexible, HTML pushed through Cache Everything, or a record proxied that should have stayed grey.

    The order of operations matters more than any checkbox. Do it in this sequence and the site stays reachable throughout, including the day you switch nameservers.

    The short version

    • Export your DNS zone and compare it against what Cloudflare imports before you change nameservers.
    • Lower the TTL on your A record a day ahead so a mistake costs five minutes, not twenty-four hours.
    • Set SSL/TLS to Full (strict) before go-live. Flexible is the most common way to break a WordPress site.
    • Keep mail, webmail and any untested subdomain on grey cloud (DNS only).
    • After the switch, run five checks — including an admin login and a form submit — before you walk away.

    Before you touch the nameservers

    The nameservers are the last step, not the first. First make sure Cloudflare knows every record your domain actually uses.

    Export the zone from your registrar or host’s DNS editor. Watch for what people forget: the MX records pointing at your mail server, SPF and DKIM TXT records, and any subdomain something else depends on — webmail, cPanel, an API endpoint, a verification record.

    Then add the site in Cloudflare and let it scan. It reliably finds A and CNAME records and usually picks up MX, but it is weaker on SRV records, some TXT values, and subdomains it cannot guess. Compare the imported list line by line against your export. A missing record is invisible now and becomes a dead mailbox or broken subdomain the moment you switch.

    Leave every record grey for now; you will turn website records orange one at a time.

    Finally, drop the TTL on your main A record to 300 seconds and wait a day. If something goes wrong mid-migration you can point traffic back in five minutes instead of waiting out a cached day — the same logic I use when moving a site between hosts, covered in how to move a WordPress site without downtime.

    The SSL setting that takes sites down

    This is the one worth reading twice. Cloudflare’s SSL/TLS mode describes how Cloudflare talks to your origin, not how visitors talk to Cloudflare. Visitors always get HTTPS; the mode decides the second leg of the trip.

    • Flexible — Cloudflare fetches from your server over plain HTTP. If the host forces HTTPS (most do), every request comes back as a redirect, Cloudflare follows it, the browser asks again, and you get an endless loop — the ERR_TOO_MANY_REDIRECTS everyone posts about. The trip to your server is also unencrypted, which defeats most of the point.
    • Full — HTTPS to your server, but the certificate is not checked, which hides a problem instead of fixing it.
    • Full (strict) — HTTPS with the certificate validated against the hostname. This is what you want, and it needs a valid certificate on the origin; a Let’s Encrypt certificate from your host’s panel is enough and renews itself.

    Set Full (strict) before you switch nameservers. If your host already provisions a valid certificate, nothing else is needed. If not, install one first — either through the hosting panel, or a Cloudflare Origin CA certificate, which is issued for this leg specifically and is trusted by Cloudflare and nothing else. It is the right tool when your host makes free certificates awkward.

    On the same page, turn on Always Use HTTPS and Automatic HTTPS Rewrites. The rewrites stop mixed-content warnings from images and scripts still loaded over http://. They do not repair URLs stored in your database — that needs a search and replace — but they stop the visible breakage.

    If the site is already down, the error code narrows it fast. 525 means the TLS handshake with your origin failed, usually no certificate for that hostname. 526 means a certificate exists but is rejected: expired, self-signed under strict mode, or issued for a different name. 521 and 522 mean the origin refused or timed out — a server problem, not a certificate one. A 500 instead points at your host, and what HTTP 500 actually means will find it faster than guessing.

    What to cache, and what to keep out

    By default Cloudflare caches by file extension: images, CSS, JavaScript, fonts. That default is safe for WordPress and it is where most of the speed gain on a small site comes from.

    The trouble starts with Cache Everything, a rule that tells Cloudflare to cache HTML too. On a brochure site that never changes, fine. On WordPress it is a trap: the same URL serves a logged-in administrator, a logged-out visitor and a customer with items in a cart. Cache the HTML and one of them gets somebody else’s page — usually the logged-out version, which is why people report being randomly logged out of /wp-admin.

    If you do want HTML cached, add two exclusions to the same rule: bypass for /wp-admin and /wp-login.php, and bypass when the request carries the wordpress_logged_in_ cookie. That cookie check is what keeps the cache from logging people out.

    Two more traps: subdomains like webmail. or cpanel. often break when proxied because they expect a direct connection or an unproxied port — leave them grey. And mail records stay grey always, because proxying mail does not work.

    The three settings behind most outages

    Symptom What is actually wrong Fix
    Endless redirect, site never loads SSL mode is Flexible while the host forces HTTPS Switch to Full (strict)
    Logged out at random, admin looks stale Cache Everything without a cookie bypass Bypass on wordpress_logged_in_
    Images or icons missing after the switch Mixed content still loading over http:// HTTPS Rewrites, then fix stored URLs
    Mail stops, site fine Mail record proxied or missed on import Grey cloud on all mail records
    Admin loads but saving a post fails Under Attack Mode or a rule blocking POST Turn it off, allow the admin path

    Under Attack Mode deserves its own warning. It is a five-second interstitial meant for an active flood, and people leave it on just in case. It breaks the REST API, form submissions and any scripted client, and it looks like a broken site to a real visitor. Turn it off when the attack ends and rate-limit instead.

    The five checks before you walk away

    These tell you what is actually happening.

    # 1. Is traffic going through Cloudflare?
curl -sI https://yourdomain.com | grep -i cf-ray

# 2. Which datacentre answered, and over which protocol?
curl -s https://yourdomain.com/cdn-cgi/trace

# 3. Is the origin certificate valid for this hostname?
curl -sI https://yourdomain.com --resolve yourdomain.com:443:ORIGIN_IP

    A cf-ray header means the proxy is live. Nothing printed means you are still hitting the origin directly. Then do the two things a terminal cannot test: log in to /wp-admin, edit a post and save it — that exercises cookies, POST and the admin path at once. Submit your contact form and confirm the email arrives, which tests the mail path. Last, load the site on mobile data; your laptop may be holding a cached DNS answer that hides the truth.

    When not to use the orange cloud

    Cloudflare is not automatically faster. If your pages are almost entirely dynamic, your host is already close to your visitors and caching only covers a logo and a stylesheet, the extra hop can cost more than it saves. Measure it: run your normal load test before the switch and again a week after, following how to test hosting speed properly, and compare time to first byte rather than a single ping.

    The reasons to keep it anyway are not speed: free TLS that renews itself, DNS that resolves fast and survives a flood, and a firewall in front of a server you do not have to harden alone.

    Do this today

    Export your DNS zone and lower the TTL on your main A record to 300 seconds. That is the whole task for today — the nameserver switch can wait until tomorrow, when a mistake costs five minutes instead of a day.

    Then set Full (strict) first, proxy one record at a time, and run the five checks before you close the laptop. That order is the difference between a quiet migration and an evening spent chasing redirect loops.