Check your site's indexing, sitemap, mobile view, speed and redirects, and turn what you find into a ranked fix list.
Priya runs a small business and wants to know whether Google can find, read and show the pages on her site that matter. She runs six technical checks, ranks what she finds, and ends up with a short list of fixes, each with a named owner.
Technical SEO tools tend to produce long reports with many colour-coded warnings, something like 140 of them (an illustrative figure, not a real site), and a score that makes the site sound broken. Most small business owners close these reports, feel bad and fix nothing. Some hire someone to fix every warning and spend weeks on issues that never affected a single customer. This exercise checks a short list of things that matter, ranks the findings and gives each fix an owner, so you finish with ten fixes at most, each tied to a page that matters.
You need Google Search Console set up for your site. If it isn't, do Lesson 9.1, "Set up and verify your site", first, then come back. Some Search Console reports need a few days after setup before they show data.
Open your keyword map. The pages marked as priority there are your priority pages, and they decide how every fix is ranked.
In your spreadsheet, add a new tab called "technical check" and log each finding there as you go. Give it six columns: item checked, what you found, pages affected, whether a priority page is affected, the fix, and the owner.
Start with indexing. The Page indexing report in Search Console shows how many of your pages are indexed and groups the non-indexed pages by the reason Google gives, such as "Excluded by noindex tag", "Page with redirect", "Not found (404)" and "Crawled, currently not indexed". For this exercise, you only need to look for priority pages in the not-indexed lists, and any priority page that is not indexed goes straight to the top of your fix list. Priya's report listed her P6 page (a label from her keyword map) as "Excluded by noindex tag", a tag left over from when she drafted the page. Lesson 9.3, "Page indexing and URL Inspection", explains each reason in detail.
Priya's sitemap was read successfully. To check yours, open the Sitemaps report and confirm it shows a success status and a sensible number of discovered pages. If it shows an error, or the sitemap was never submitted, note it on your tab. You created and submitted your sitemap in Lesson 4.2, "Sitemaps and getting new pages found".
Priya's robots.txt was fine. To check yours, open your domain followed by /robots.txt and read the file, looking for any rule that blocks pages you want found, especially a blanket "Disallow: /", which blocks the whole site. Lesson 4.1, "Robots.txt, noindex and canonicals do different jobs", gives you the knowledge you need to read it.
HTTPS worked on every one of Priya's pages. To check yours, visit your homepage and a few inner pages, typing each address with http instead of https, and confirm each page switches to the https version with no browser warning.
For the mobile view, open each priority page on a phone and confirm the main text, headings, images and links are all there. On Priya's P5 page, the reviews section was hidden on mobile. Lesson 4.3, "Mobile-first indexing and page experience", covers what to check in the mobile view.
For speed, run PageSpeed Insights on the mobile setting, but don't test every page. Most sites are built from a few templates, for example a homepage, a service page, a blog post and perhaps a product page. A template is the shared layout that several pages are built from, and pages on the same template usually share the same issues, so test one example of each template and note its top two issues. For Priya, PageSpeed Insights flagged a large hero image on her service template and a slow map embed on her contact page.
Rank your findings by their effect on priority pages. A suggested order:
anything that stops a priority page being indexed anything that breaks the mobile view or HTTPS on priority pages sitemap and robots.txt problems speed issues on templates that priority pages use everything else
Every fix needs a named owner. You can usually do some fixes yourself, such as a noindex setting, a missing redirect or an oversized image. Others need a developer or your website builder's support team, such as changes to the theme's code or to server settings. For each of those, write a two-line brief that names the page, says what PageSpeed Insights or Search Console reports, and states the outcome you want. A clear brief saves the developer time and saves you money.
Priya's check found four issues, and she ranked them like this. First, remove the noindex on the P6 page and request indexing, owned by Priya. Second, change the theme setting that hides reviews on mobile, owned by Priya using the theme's help pages. Third, compress the hero image on the service template, owned by Priya. Fourth, move the map lower on the contact page or load it only when tapped, owned by a developer with a short brief. Her list came to four fixes, three of them hers, all on pages that matter.
If your list is longer, cut it at ten. Anything below ten waits for next month's review, which you set up in Lesson 9.4, "Build your monthly SEO review routine".
Open Search Console and your spreadsheet and work through each check in turn. The activity below asks you to finish with your own ranked list and an owner for every line.
Complete the technical health checklist, then write a ranked list of up to ten fixes with an owner for each.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).