Fix Your WordPress SEO Setup Before You Publish Anything

Why does publishing onto a broken WordPress setup waste every article you write?

Publishing onto a broken WordPress setup wastes every article because the content still has to travel through your URLs, your templates and your server before it reaches a single reader. A sharp 2,000-word guide sitting at a URL like /?p=417, on a page that takes six seconds to paint, with a canonical tag pointing somewhere else entirely, is a sharp guide nobody finds. Search engines and AI assistants both judge pages through the same plumbing. Fix the plumbing once and everything you publish afterwards benefits from it; skip it and you pay the same tax over and over, on every single piece.

The contrast with paid ads is the whole argument for getting this right. A campaign stops the day you stop funding it. An article on a properly configured site keeps earning clicks for years, and each new piece raises the topical authority of everything around it. That compounding only works if the foundation holds. Publish thirty articles onto a site with duplicate URLs, no sitemap and a four-second load time and you haven't built an asset — you've built thirty pages competing with each other for a crawler's limited attention. The setup work is a one-time cost. The absence of it is a recurring one.

Here's the honest split between what you can do and what you should hire out. Permalinks, the sitemap, Search Console verification, title templates, noindex rules and robots.txt are point-and-click work you can finish in an afternoon with no code at all. Anything touching the server or the theme — time to first byte, render-blocking scripts, a page builder shipping megabytes of CSS, hreflang your plugin outputs incorrectly — is developer territory, and pretending otherwise burns a weekend. Do the settings yourself, measure, then hire once you know which number is failing. "Make the site faster" gets you an invoice; "TTFB is 900ms on the blog template" gets you a fix.

Which WordPress settings should you lock down before your first post?

Three settings matter more than everything else in the WordPress admin: permalinks set to post name, one canonical version of your domain running over HTTPS, and the "Discourage search engines from indexing this site" box unchecked. That last one is a staging leftover that has quietly killed more launches than any algorithm update. Under Settings → Permalinks, pick post name, or category plus post name if your structure genuinely calls for it, and do it before the first article goes live. Changing the structure afterwards means a redirect map for every URL you've published, plus a recovery window nobody can predict for you.

Set your title and meta description templates once, in the plugin, rather than writing them by hand forever. Yoast SEO and Rank Math both let you define a pattern — post title, separator, site name — that applies sitewide, with a manual override on the handful of pages that earn one. While you're in there, handle index hygiene. Auto-generated tag archives, author archives on a one-person blog and internal search result pages are thin by nature, and letting them into the index spreads crawling across pages that will never rank. Noindex those; keep curated category archives, which often do rank.

Plan your internal linking before you have anything to link. Decide on the two or three pillar pages that describe what you actually sell, then commit to a rule: every article links up to its pillar and sideways to two or three siblings covering related questions. This is the cheapest ranking signal available in WordPress and the one most sites neglect until they're sitting on ninety orphaned posts and nobody has the appetite to untangle them. Keep slugs short, lowercase and descriptive — three to five words, no dates, no filler. And resist renaming a slug after publication unless you're ready to set up the 301.

How do you get your sitemap, robots.txt and Search Console working together?

Your sitemap, robots.txt and Search Console are one system, not three separate chores. Yoast, Rank Math and WordPress core all generate an XML sitemap automatically — usually at /sitemap_index.xml — so the job isn't creating it, it's opening it in a browser and confirming it lists only pages you'd be pleased to see ranking. Then verify ownership in Google Search Console and submit it, and repeat the exercise in Bing Webmaster Tools, which feeds more of the AI answer ecosystem than most people assume. Add a Sitemap: line at the bottom of robots.txt so any crawler finds it unprompted.

The classic WordPress robots.txt mistakes are blocking /wp-content/ wholesale, blocking CSS and JavaScript, and confusing three tools that do genuinely different jobs. Robots.txt controls whether a crawler may request a URL at all. A canonical tag tells search engines which of several similar URLs is the real one. Noindex keeps a single page out of results. They aren't interchangeable, and combining them badly backfires in a way that's hard to diagnose: a page blocked in robots.txt can't be crawled, so the noindex tag sitting on it is never read, and the URL lingers in results regardless. Block almost nothing; exclude with noindex.

If you sell in more than one language, hreflang decides whether the Hebrew page or the English page reaches the right person. Polylang and WPML both output hreflang automatically once you connect translations, so your job is verification rather than hand-coding: view the page source, confirm every language version lists every other one plus itself, and check that x-default points where you intend. Use subdirectories rather than separate domains unless legal or team structure forces your hand — one domain, shared authority, far less maintenance. And never let an internal link inside the Hebrew site drop a reader onto an English page.

Do you have to pass Core Web Vitals before you publish your first article?

You don't have to pass Core Web Vitals before publishing, but you do need to fix anything genuinely broken, and the bar is public: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1. Those are measured on real visitors at the 75th percentile over a rolling 28-day window — not in a lab test on your laptop over office fibre. That distinction matters more than people expect. A flawless synthetic audit means very little when a quarter of your readers are on mid-range phones over mobile data. Speed won't rank a mediocre article, but it will quietly cap a good one.

On WordPress, slow almost always traces back to the same short list: cheap shared hosting, no page caching, an oversized hero image, and a page builder shipping heavy CSS and JavaScript on every single view. Start with server response time. If time to first byte sits above roughly 600 milliseconds, no amount of frontend tuning rescues you, because that's the floor everything else builds on. Managed hosting with server-level caching, a current PHP version and a CDN typically fixes more in one afternoon than six optimization plugins fixed all year. After that: compress images, serve WebP, self-host your fonts.

Then get specific. Find the element PageSpeed Insights actually flags as your LCP — it's frequently a slider or a banner rather than the image you assumed — and make sure it loads at high priority. WordPress has applied fetchpriority to the first content image automatically since version 6.3, but unusual theme markup and featured-image handling routinely send it to the wrong element. INP is now the metric most sites fail, and the usual suspects are third-party scripts: chat widgets, heat maps, a tag manager stuffed with forgotten tags. CLS is the easy win — set explicit dimensions on images and reserve space for anything injected after load.

How do you make sure AI crawlers can actually read your WordPress site?

Making your site readable to AI assistants starts with not blocking their crawlers by accident. Each AI company now runs several bots with different jobs, and each needs its own rule: OpenAI's GPTBot gathers training data while OAI-SearchBot powers ChatGPT's search answers, and Anthropic splits ClaudeBot, Claude-SearchBot and Claude-User along the same lines. Blocking one does nothing to the others. Plenty of sites still carry a blanket disallow left over from the 2023 panic, and the cost is real — you vanish from AI answers while your Google rankings, which depend on Googlebot alone, look perfectly healthy on the dashboard.

Check three places, not one. Your robots.txt at the domain root is the obvious one. A security plugin that challenges unrecognised user agents is the second. Your CDN is the third, and the sneakiest — bot-management settings can turn AI crawlers away before the request ever reaches WordPress, whatever your file says. Then read your server logs for those user agents and watch for 403 responses, which mean something upstream is refusing them. One more trap worth knowing: noindex applies to AI search crawlers too, so any page you'd like quoted in an answer has to be indexable in the ordinary sense first.

Which brings us to llms.txt — a plain markdown file at your domain root pointing models toward your best pages. Worth twenty minutes; not worth a strategy meeting. It's a community convention with no standards body behind it, Google has said plainly that it doesn't use it, and log studies show the major crawlers overwhelmingly request ordinary HTML instead. Add it because it costs nothing, then earn citations the way they're actually earned: clear headings, a direct answer in the first two sentences of every section, real topical depth. If you want a read on where you stand, see how visible your site is in AI answers.

Get the foundations right once and the rest is a publishing problem — researching topics worth ranking for, writing them properly, keeping them interlinked, and tracking whether Google and the AI assistants are actually citing you. That's the part that never ends, and it's the part artiql runs on autopilot: topic research, native-language articles published straight onto your own domain, video versions for social, rank and AI share-of-voice tracking, with a review queue so nothing goes live unseen. If that sounds like the bottleneck in your setup, book a demo and we'll look at your site together.

Frequently asked questions