Key takeaways
- Why you need WordPress and SEO services together: most traffic losses after a new site are decided during the build, not after launch.
- Google itself says a great time to hire an SEO is when you are considering a redesign or planning a new site, “the earlier, the better”.
- Six mistakes come up again and again: a live site still set to discourage search engines, a staging robots.txt copied to production, URLs changed without redirects, design that hides content, plugin weight, and local details only in images.
- Every one of them is cheap to prevent and slow to repair.
- You don’t need two big contracts. You need the SEO in the room at four points: the brief, the wireframes, the pre-launch check and the first weeks after launch.
If you are wondering why you need WordPress and SEO services together, here is the short answer: the developer decides how your site is built, and how it is built decides what Google can crawl, index and rank. When the two jobs are done separately, the developer ships a site that looks right and the SEO is called in afterwards to find out why the traffic fell.
I have worked in SEO and digital marketing for more than 16 years, and a large share of my WordPress work is repair after a launch or redesign that went ahead without anyone checking search. The developers were usually good at their job. The problem is that nobody owned the search side of the decisions they made. This article covers the mistakes I see most, why they happen in silos, and the small amount of joint working that prevents them.
Why you need WordPress and SEO services together
Google’s own page on hiring an SEO says “a great time to hire is when you’re considering a site redesign (the earlier, the better), or planning to launch a new site. That way, you and your SEO can ensure that your site is designed to be search engine-friendly from the bottom up.”
That is the core of it. Search decisions are mixed into build decisions: which URLs exist, which templates carry which headings, what loads on every page, what happens to old pages. A developer working to a design brief makes dozens of these choices without knowing they are search choices. An SEO brought in after launch can only list what went wrong.
Six costly mistakes when developers and SEOs work apart
These are the six I find most often after a WordPress launch or redesign. None of them is exotic.
| Mistake | How it happens in a silo | What it costs | What prevents it |
|---|---|---|---|
| 1. Live site still discourages search engines | Setting ticked during the build, never unticked | Pages drop out of Google | One line on the launch checklist |
| 2. Staging robots.txt copied to live | Developer blocks staging, then deploys the files | Google can’t crawl the site | Check robots.txt on launch day |
| 3. URLs changed without redirects | New permalinks or structure, old pages left to 404 | Rankings and links of old pages lost | A redirect map agreed before build |
| 4. Design hides or drops content | Text cut to fit the design, headings used for styling | Pages lose what made them rank | SEO review of wireframes |
| 5. Plugin and builder weight | Features added one plugin at a time | Slower pages on every template | Agreed performance budget per template |
| 6. Local details only in images | Address and hours in a graphic or footer image | Google can’t read key business facts | Text details and structured data in the spec |
1. The search engine visibility setting left on
WordPress has a setting called “Discourage search engines from indexing this site”. The WordPress Reading Settings documentation explains that since version 5.3 it adds a robots meta tag with noindex,nofollow to your pages, and notes it is “up to search engines to honor your request.” Developers often tick it on a build so the half-finished site stays out of search, which is sensible. The problem is when nobody unticks it at launch. I covered where this sits in a WordPress review in the first 30 days of WordPress SEO consulting, so here I will only say: put it on the launch checklist by name.
2. A staging robots.txt that reaches production
The other common way to hide a staging site is a robots.txt file that blocks all crawling. If that file is deployed with everything else, Google can’t crawl the live site. It also interacts badly with noindex: Google’s noindex documentation says that for noindex to work, “the page or resource must not be blocked by a robots.txt file.” So a site with both blocks in place can be very hard to diagnose for someone who wasn’t there when they were added. Password protection on staging is often the cleaner option, and it is a choice the developer and the SEO should make together.
3. URLs changed without a redirect map
This is the most expensive mistake on the list. A redesign changes the permalink structure, merges categories or renames service pages, and the old URLs simply stop working. Google’s guide to site moves with URL changes is clear about the steps: “It’s important to map your old site’s URLs to the URLs for the new site,” use permanent redirects such as 301 or 308, change internal links to the new URLs, update sitemaps, and “Keep the redirects for as long as possible, generally at least 1 year.” It also warns that “you may experience ranking fluctuations while Google recrawls and reindexes your site,” even when the move is done properly.
The developer can implement redirects in minutes. Deciding which old URL should go to which new one, and checking that nothing valuable was missed, is SEO work. Split the job that way and agree the map before the build starts, not on launch night.
A redirect map takes an afternoon to agree before launch and weeks to rebuild after it.
4. Design that hides or drops content
Designers work to make pages clean, and clean often means shorter. Text that answered real searches gets cut, product details move into tabs or sliders, and heading tags are chosen for their size rather than their meaning. None of this is wrong in itself. It becomes a problem when nobody checks whether the page still answers the searches it used to rank for. An SEO looking at the wireframes can flag that in a short call, at the stage where changing it costs nothing.
5. Plugin and page builder weight
WordPress makes it easy to add features, and each plugin seems harmless on its own. The total is what slows every template. In audits I often find sliders, form tools, chat widgets and tracking scripts loading on pages that don’t use them. A short performance budget agreed per template (what may load on a product page, what on a blog post) keeps the developer and the SEO looking at the same target.
6. Local details the site can’t state in text
For local businesses this is the quiet one. The address, phone number and opening hours sit in a footer image or a map embed, so they are not on the page as text at all. Google’s LocalBusiness structured data guide lists name and address as required properties and recommends others such as telephone, url and openingHoursSpecification. Those details need to exist as text and markup, which is a development task with an SEO specification behind it.
WordPress web design and SEO: where the SEO joins each stage
You don’t need an SEO in every meeting. You need one at four points, each short.
- The brief. Which pages earn traffic now, which searches the new site must serve, and which URLs must survive or be redirected.
- The wireframes. Whether key pages keep the content that ranks, how headings are used and how internal links flow. Our work on SEO website structure usually happens here.
- The pre-launch check on staging. Redirects tested, indexing settings, robots.txt, titles and canonicals on each template, page speed on the heaviest templates.
- The first weeks after launch. Search Console coverage, redirect errors and ranking movement, so problems are found while they are small.
Custom WordPress development services for local SEO
Local businesses get the most from joint working, because so much of local search depends on details the developer controls. Location pages need their own URLs and real content, not one page with a list of towns. Business details need to be in text and structured data that match your Google Business Profile. Forms and click-to-call buttons should work properly on phones.
None of this needs an expensive custom build. It needs the developer to know what the SEO needs before they choose a theme or a location plugin. Our local SEO work starts from exactly that specification.
A shared launch checklist
This is the list I ask developer and client to sign off together before a WordPress site goes live.
WordPress launch checklist for developer and SEO
- “Discourage search engines” is unticked on the live site.
- The live robots.txt is the production version, not the staging one.
- Every URL in the redirect map returns a permanent redirect to its new address.
- Internal links and menus point to new URLs, not to redirects.
- The sitemap lists the new URLs and is submitted in Search Console.
- Each template has a unique title pattern, one main heading and the right canonical.
- Business name, address, phone and hours appear as text, with structured data where relevant.
- The heaviest templates have been tested for speed on mobile.
If any item can’t be ticked, the launch waits a day. That day is cheaper than the weeks it can take to recover.
How I work with your developer
I charge by the hour, with no fixed packages, which suits this kind of work: a few hours at the brief and wireframe stages, a pre-launch check, and a review in the weeks after launch. I write findings as tickets your developer can act on, with the reason for each. I don’t need to replace your developer, and I don’t build sites. My job is to make sure the search side of each decision has an owner. You can see how this fits our wider WordPress SEO consulting, and what a full scope covers in what should be in a WordPress SEO services scope.
FAQ
Can my web designer handle WordPress web design and SEO on their own?
Some can, and many handle the basics well: clean templates, an SEO plugin, decent speed. The gaps tend to be redirect mapping, indexing decisions and content that ranks. If your designer has done several redesigns without traffic losses, ask how they handled redirects; their answer will tell you whether you need extra help.
When should the SEO join a WordPress project?
At the brief, before design starts. Google says the best time to hire is when you are considering a redesign or planning a new site, the earlier the better. Joining after launch means the SEO can only report what went wrong.
Do I need custom WordPress development services for local SEO?
Usually not a fully custom build. You need location pages with real content, business details in text and structured data, and forms that work on mobile. A good developer can do this with a standard theme if they have a clear specification from the SEO.
What if my site has already launched without SEO input?
Start with the checks on the launch checklist above, then compare Search Console data before and after launch to find the pages that lost traffic. Missing redirects can still be added, and the sooner the better. A short technical audit will tell you what else needs fixing.
Is it more expensive to use WordPress and SEO services together?
It usually costs less overall, because the SEO time is a few hours at set points instead of a repair project after launch. Fixing a redirect map, a blocked site or lost content after the fact takes longer than preventing it.
If you are planning a WordPress redesign or a new site, talk to me before the build starts and we can agree what your developer needs from the SEO side.
Eugen Platon · SEO consultant with 16+ years in SEO and digital marketing · free 10-minute first call