The audit PDF is still in Downloads. Live titles still append the tagline. The archive H1 is the site name. Schema is whatever the plugin dumped into the header the day it was installed.
That gap is the job. Findings on paper do not change how Search reads the templates.
We treat wordpress seo implementation as template work plus editor work, in that order, so one theme change does not get overwritten by the next post save.
The pdf is not the site
An audit lists what is wrong. It does not rewrite the document title, move the H1, or stop a second plugin from printing another Organization graph.
Open the PDF beside a staging copy of the theme. If a finding names a template - home, archive, single, product - the fix belongs in that template, not in a sticky note on the homepage.
If a finding names one URL, we fix that URL in the editor after the template is clean. Mixing the two is how the same title pattern comes back on every new post.
We do not implement from memory. We implement from the finding, the template file, and the rendered source, in that loop. If those three disagree, the rendered source wins.
A score at the top of the PDF is not a queue. The queue is the list of URLs and the templates that generate them.
Titles before anything in the body
Search reads the title element first. If the theme still concatenates post name, separator, site name and tagline, every later heading rewrite is noise.
Check three places, not one.
The SEO plugin title template for each post type. The theme’s document title filter, or a hardcoded title tag in header.php that ignores `add_theme_support( 'title-tag' )`. The Open Graph title, which often still pulls `the_title()` after the SEO title was changed.
They have to agree. A rewritten SEO title with an old og:title is how the wrong string shows up in a share, then gets recrawled as if it were the document title.
Per-post titles in the editor only hold if the template does not force a pattern. We lock the pattern first, then write the exceptions for the URLs the audit actually named.
Archive titles need their own pass. WordPress still loves a “Category:” prefix. Shop pages often inherit the site name. Author archives, date archives and tag indexes frequently share one useless pattern. Those are template strings, not twenty separate editor tickets.
That is on page seo wordpress work at the template layer, not copywriting yet.
Headings that fight the template
A common audit line is “H1 missing” or “multiple H1s”. On WordPress that is almost never the paragraph. It is the hero, the logo wrap, or `the_archive_title()` printing inside an H1 that already exists in the header.
View source on the live URL. Count H1s. If the theme prints one and Gutenberg prints another, we remove one. We do not add a third “for SEO”.
Cover blocks often output the post title as an H2 on top of a template H1. Query Loop blocks print card titles as H2s on an archive that already has an H1 and a list of H2s. Related-posts widgets and comment headings steal outline weight if they are H2s.
We change the template heading level, then we tidy the blocks. Doing it only in Gutenberg leaves the next landing page with the same broken outline.
H2s should outline the page the way a person would scan it. If the first H2 is “Leave a comment”, the outline is lying.
Schema in the theme, not the post
Most WordPress sites end up with two graphs. The SEO plugin prints Article or Product. The theme, or a second plugin, prints Organization and WebSite. A page builder then adds FAQ on top of an FAQ the editor already added.
Audit findings that say “duplicate schema” or “invalid node” are template findings. We keep one graph, one publisher, one mainEntityOfPage that matches the canonical.
We do not paste JSON-LD into a Custom HTML block on every post. That dies the first time someone clones a draft.
BreadcrumbList belongs in the template that already draws the breadcrumbs. If the visual trail and the graph disagree, Search trusts neither.
FAQ and HowTo nodes only stay if the FAQ or steps are visible on the page. Hidden accordion schema is a cleanup item, not a ranking trick.
WooCommerce adds its own Product graph. If the SEO plugin also prints Product, we pick one and turn the other off for product types. Two offers, two SKUs, two availability nodes - that is the audit finding, and it is a plugin setting, not a product edit.
Organization logo must be a real image URL that loads. sameAs should be the profiles you actually own. Empty sameAs arrays are clutter.
On page work inside the editor
Once titles, headings and schema are stable in the theme, the remaining findings are URL-level.
That is the body, the excerpt, image alt in the block, and internal links that point at the URLs that matter.
Rewrites on the live URLs - titles in the editor, headings, alts, internal links - sit in on-page SEO services in the Philippines after the templates stop fighting the head.
Editor work we actually ship:
Rewrite the SEO title and meta description to match the H1, not the old tagline pattern.
Put one H1 in the content if the template no longer prints it.
Turn stacked H2s into a real outline.
Fix alts that still say IMG_4031 or the filename.
Add internal links from the body, not a related-posts widget that randomises every cache flush.
The first paragraph should answer the query the title already claimed. We do not open with the company name, and we do not repeat the keyphrase three times before the first full stop.
Excerpts are not decoration. Category cards, search results on-site, and some Open Graph fallbacks still read the excerpt. If it is blank, WordPress invents a snippet from the first paragraph, which may be a cookie notice or a hero button label.
Media library alts do not always flow into the block. Check the image block on the live URL, not only the attachment screen.
Valid metadata so the rewrite can stick
A title change that never appears in results is often invalid markup, not a slow recrawl.
Conflicting title tags, empty descriptions, a robots meta that still says noindex on a URL we meant to open, or a canonical that points at a parameterised version of itself - Search will ignore the pretty rewrite.
We check the rendered head against Google valid page metadata before we call a URL done. Unique title, sensible description, consistent canonical, robots that match intent.
If Rank Math and the theme both print a description, we keep one. Two description metas is how the old one wins.
Canonicals on paginated archives should be self-referencing, not forced back to page 1. Filter and sort URLs from FacetWP, WooCommerce attributes or page-builder query strings need a rule: index the clean URL, noindex or canonical the rest, and do not leave both in the sitemap.
After the head is clean we request indexing on the URLs that changed, not the whole sitemap at once.
Search Console’s “last crawled” title is the title that matters, not the one in the plugin preview. If they differ, the live HTML is still wrong, or cache is still shipping the old head.
Templates we change once
Home, blog index, category, single post, page, product, product category, and search. Those eight cover most of the audit.
We fix each as a template, then sample three live URLs that use it. If the sample is clean, we do not hand-edit the other two hundred.
Child theme, always. A parent update that restores the old header.php is how last quarter’s implementation vanishes.
When the blocker is the theme - title output, heading markup, schema in header.php, archive H1 - that is WordPress development on the templates, not a plugin toggle.
Page builders complicate this. If the H1 lives in a global hero, we change the global, not thirty landing pages. If the builder nests H2s inside nested columns, we flatten the outline in the builder, then lock the global.
Custom post types inherit the post template until someone tells them not to. If the audit names case studies, services, or locations as thin or duplicated, look at `single-{type}.php` and the SEO plugin’s template for that type before rewriting ten drafts by hand.
Plugins that double the output
One SEO plugin. One schema source. One cache plugin whose HTML minify does not strip `application/ld+json`.
Audits often show “plugin bloat” as a speed finding and “invalid schema” as a separate finding. They are the same mess. Two SEO plugins, or SEO plus a schema plugin plus the theme’s built-in graph.
We disable the duplicate, then re-render. We do not add a third plugin to “fix SEO”.
Sitemap: one. The SEO plugin’s sitemap, submitted in Search Console, with the theme sitemap and any leftover XML Sitemap plugin gone. Include the post types you want crawled. Exclude thank-you, account, cart, checkout, and the old landing pages that 301 away.
Cache and CDN are part of implementation. If production still ships the old title after a template fix, the work is not live. Purge the page, then purge the HTML at the CDN, then view source in a private window. Minify that concatenates script into the JSON-LD block will invalidate the graph even when the plugin preview looks perfect.
Sequence that keeps the live site searchable
We never start by noindexing half the site “while we work”. That is how a two-week implementation becomes a recovery project.
Order we use:
Staging clone with the same plugins, permalinks and builder.
Template titles, headings, schema, canonicals.
Render-source check against the findings on sampled URLs.
Cache and CDN rules so the new head actually ships.
Production deploy of the child theme and plugin settings.
Then the URL-level editor changes, in batches, with indexing requests after each batch.
If production cannot wait for a full staging cycle, we still do templates first on production in a child theme, during a quiet window, with a rollback commit.
Do not rewrite two hundred meta descriptions before the title template is fixed. You will type them twice.
Do not change permalinks in the same window as titles and schema unless the audit explicitly requires it. That is a migration, and it needs redirects mapped before anyone hits save.
What done looks like on one url
Pick one URL the audit named. Done means all of this, not a green plugin traffic light.
View source: one title, one meta description, one canonical, robots that match intent.
The title in the tab, the SEO plugin, and og:title are the same string, or a deliberate short variant, not three different slogans.
One H1. H2s outline the sections a person would use.
One schema graph. The type matches the page. The canonical in the graph matches the link rel canonical.
Images in the body have alts that describe the image.
The first paragraph is usable without the hero overlay.
Internal links in the body go to live URLs, not /?p= old IDs.
Search Console URL inspection, after a purge, shows the new title in the rendered HTML, not only in “last crawl”.
If any of those fail, the URL is not implemented. The PDF can wait. The head cannot.
What we need from the audit
The PDF is useful if it names URLs, templates, and the exact string that is wrong.
We need the crawl or the list of URLs, not just a score. We need to know which findings are template-level versus URL-level. We need access to staging, or a clone we can make. We need to know which SEO plugin is canonical, and login to it. We need to know whether a page builder owns the H1. We need Search Console so we can see the title Google last stored, not only the one in the plugin.
If the audit is ours, we already have that map. If it is someone else’s PDF, we re-crawl before we touch templates. PDFs drift. The live head is the source.
A finding without a URL is a workshop note, not an implementation ticket. “Improve on-page SEO” is not a ticket. “Category template title is `%term% | %sitename% | %tagline%`” is a ticket.
Theme and plugin update history matters. If the parent theme updated after the audit date, assume header.php and archive titles moved. Implement from a fresh crawl.
The next useful step
Open the PDF. Mark each finding T or U - template or URL. If you cannot tell, view source on one live example and see whether the bad string sits in the theme or in the post.
If most marks are T, the next useful thing is the child theme and the title, heading and schema templates. Editor copy can wait.
If most marks are U and the head is already clean, the next useful thing is the URL list in the editor, starting with the pages that already get impressions in Search Console.
If the PDF is older than the last theme update, do not implement from it. Re-audit the live head first. We will scope that if the site and the findings still match how we work.
Send the PDF, who owns the theme, which SEO plugin is live, and Search Console. We will say whether this is template work, editor work, or both, and in which order.
