Library·SOP·SEO
Choose the right guide to investigate and fix WordPress indexing, crawling, redirects, broken links, or page-speed problems.
Last reviewed: · Editorial review
Clarity, structure and references reviewed in this version. This is not a test in a live account.
Choose the right guide to investigate and fix WordPress indexing, crawling, redirects, broken links, or page-speed problems.
This SOP covers:
This does not cover:
Start from a real concern or existing report. This guide helps choose the next procedure; it does not ask you to audit every page or make the fix now.
Open the Technical SEO action plan. If you already have a copy from this set of guides, reuse it. Otherwise make one copy for this website.
In Start here, enter Website, Review date, and Reviewed by. For Search Console findings, copy the displayed update date into Indexing report last updated, or write Not shown if there is no date. In Action plan, add one row for each distinct concern. Use Page or issue for the page or symptom, What you found for the exact report or observed evidence and its date, and Next action for the question you still need answered.
Use the narrowest route that fits the evidence. A missing URL, a group of URLs, a confirmed crawl rule, a permanent move, and a slow-page symptom need different checks.
If you want to look for problems across the website, use the linked Semrush audit guide.
Bring the website address and the pages visitors most need, such as your main service page or shop. The audit guide supplies its own worksheet.
After the audit, add the findings you want to act on to Action plan. Put the checked problem and affected pages in What you found, and the suggested fix or next check in Next action.
For a Search Console concern, first decide whether you have one URL to check, a report group, or only a sitemap question.
If one important page is missing or its selected canonical address is uncertain, follow the guide for checking that page in Search Console. Carry its exact URL and the business reason that page should appear.
If several URLs appear under a Search Console Page indexing reason, or you do not know which reasons affect important pages, follow the report-level guide. Carry the reason name, affected-page count, report update date, and one representative URL. Search Console data can lag behind recent changes.
If the only question is which WordPress sitemap to submit or check, and no important missing page is confirmed, use the sitemap guide chooser. Keep the task below a confirmed block until you know an important page is affected; sitemap submission alone does not guarantee indexing.
If the page is intentionally excluded, such as a checkout or duplicate address, set Should this page be indexed? to No and Status to Expected exclusion in Indexing review. In Action plan, set Status to No change needed and record why the exclusion is expected.
For a crawl block, broken link, or redirect problem, choose the guide that matches what visitors encounter.
Use the Rank Math robots.txt guide only when a specific live rule is confirmed to block an important public page or resource and Rank Math is the editor for that file. Carry the exact rule, affected path, and important page or asset that must remain crawlable. If the cause is still only a broad indexing complaint, inspect the URL or report first.
If one old URL has permanently moved and a live, closely related replacement exists, follow the single 301 guide. Carry the old URL, final replacement URL, and the reason the new page serves the old page's purpose.
If several old URLs each have a known, relevant replacement, follow the bulk redirect guide. Carry the complete old-to-new map and mark unresolved destinations for review; do not import guessed or unmatched rows.
If a link leads to a missing page, follow the linked broken-link guide. Bring the page containing the link and the address it opens. The guide helps you choose a replacement, remove an outdated link, or redirect a page that genuinely moved.
If a URL passes through several redirects or keeps sending you back to an earlier address, follow the linked redirect-repair guide. Bring the starting URL and the page visitors should reach.
If a page was deliberately removed and there is no useful replacement, record No change needed in Action plan and ask the editor to remove links to it. Sending visitors to the homepage would not answer their original need.
For a slow-page concern, get comparable evidence before selecting an implementation guide.
If all you have is a slow-page complaint, a single report, a low score, or missing field data, follow the PageSpeed Insights guide first. Carry the important page URL and visitor task; test the same page and device so the guide can separate field evidence from repeated simulated findings.
Only when repeated reports point to an oversized important image as the visible content that loads slowly, follow the image guide. Carry the image URL or page and the repeated PageSpeed finding.
Only when an important public WordPress page repeatedly shows slow server response should you consider the simple page-cache guide. Carry the page, device, repeated response-time clue, and any existing cache evidence; that guide checks compatibility before setup.
If repeated evidence points to theme code, scripts, hosting, a CDN, layout, or a cause you cannot identify, assign a developer or host specialist. Include the affected URL, device, metric, repeated finding, and report links; leave the cause open until that owner checks it.
Prioritize by visitor impact and evidence strength. Then give the next owner enough information to complete one clear task and report what happened.
Compare the remaining candidates by (1) whether they block an important visitor task or an important page from being found, (2) how many important pages are affected, and (3) how clearly the evidence identifies the cause. Put a confirmed accidental block on an important service page ahead of an ordinary speed opportunity. Put expected exclusions and unconfirmed score-only concerns lower.
Move the chosen task to the top of Action plan and complete its Next action, Why this comes first, Owner, Review date, and Status fields. Use To do for ready work, Waiting when an owner or evidence is missing, In progress when work starts, Done when the result has been checked, or No change needed for an expected exclusion. Keep one distinct cause per row.
For Search Console groups, keep one row per relevant reason or distinct finding in Indexing review. Fill the exact reason, affected-page count, example URL, Should this page be indexed? choice, inspection finding, next action, priority and why, owner, recheck date, and status. Use Yes, No, or Unsure for the index choice and To investigate, Action planned, Waiting for Google, Resolved, or Expected exclusion for status.
Before handing off, copy the evidence the selected route needs into What you found or Next action: the page or URL, report reason or measured clue, check date, and what should happen for visitors. After the owner completes the work, use Result / how to undo to record the observed result and any reversal path.
