Give each page a clear job
Begin with the visitor's question. A service page should explain the work, scope, and next step. A guide should help someone complete a task or make a decision. Define that job before reviewing technical reports, so performance improvements support a clear user outcome.
Google's starter guidance emphasizes useful, original content and discoverable links. Turn that into an editorial review: can a new reader understand the page title, find the answer, and navigate to a relevant next page? For example, connect a launch checklist to the service that helps implement it, using a descriptive link. Avoid creating several near-identical pages simply to vary a search phrase.
Read the measurements correctly
The good Core Web Vitals thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1. Assess all three at the 75th percentile, separately for mobile and desktop. They describe loading, responsiveness, and visual stability.
Use field data to understand observed visits and laboratory tests to investigate reproducible problems. A standard Lighthouse page-load test cannot measure INP without interactions. Its performance score is not a replacement for the three field metrics.
Review the homepage, a service page, a long article, and an interactive form in every language. Record the test date, device conditions, page version, and whether results describe the URL or a broader group. When field data is absent, mark it as missing evidence and continue with controlled tests.
Change the bottleneck you can observe
For a slow main-content render, inspect the request sequence: is the delay before the server responds, before the important image is requested, or while the browser prepares to display it? For an unresponsive menu, reproduce the click and inspect the work that follows. For a moving layout, identify the element that displaced the content.
A practical first pass is to remove assets that serve no current purpose, size images for their displayed role, reserve space for media, and review third-party scripts. Let the trace determine which change deserves priority. Avoid applying every optimization suggestion in a report at once.
Save before-and-after results under comparable conditions. Complete the original visitor task again, including keyboard use and form validation. A faster page that loses a required interaction still needs repair.
Check discovery, indexing, and preferred URLs
Use Search Console's URL Inspection to examine important published pages. Google finds content through links, so confirm that an article is reachable from your site's navigation or related content. Check that the public page displays the intended text and that a forgotten staging restriction is not hiding it.
For duplicate URLs, align internal links, sitemap entries, and canonical declarations. Google treats canonical annotations as signals. Robots.txt does not reliably remove a URL from the index, and noindex is not a substitute for consolidating duplicates.
Create a URL worksheet: intended public address, response, indexability, and canonical target. Investigate contradictions, such as a canonical pointing to a redirect or unrelated homepage. Check crawling, indexing, and canonical selection separately; success in one does not establish success in the others.
Review every language as a complete product
Google's hreflang guidance requires reciprocal references, including each page itself, with fully qualified URLs. Validate supported language and script codes separately from your application's locale keys; do not assume a key such as ckb is automatically a supported Google hreflang value. Keep canonicals aligned with the page's language.
Maintain a mapping between equivalent articles and their published translations. Only advertise an alternative when that complete page exists. Test the language switcher from an article, not only from the homepage, and confirm it preserves the reader's context.
For Arabic and Sorani Kurdish, review right-to-left layout, mixed-direction code, punctuation, headings, and mobile navigation. Read the translated examples and calls to action as well as the body. Assign an owner to update all versions when an instruction changes.
Describe only what the page actually contains
Google requires structured data to represent visible, relevant content, and correct markup does not guarantee a rich result. Follow the documentation for the particular feature and use the Rich Results Test for technical validation.
For a guide, verify that the stated author, publication date, title, and related entities match the page. Do not invent ratings, reviews, affiliations, or business details to populate a template. If the content model cannot supply a trustworthy value, remove the unsupported claim.
Keep a representative markup sample with the template review. Recheck it when the template or content fields change; one successful test cannot cover every future article.
Finish with a repeatable review
Choose a small batch of improvements and record the expected benefit before release. This makes later reviews useful even when traffic is too limited to establish a trend.
- Every reviewed page answers a defined visitor question and has a clear next step.
- Performance evidence identifies the page, device conditions, and data source.
- Important pages are linked, accessible, and free of unintended indexing restrictions.
- Preferred URLs and published language alternatives agree across the site.
- Structured data matches visible facts and passes the relevant technical checks.
- An owner will review errors, user-task completion, and search observations after release.
Your next step
Performance and technical SEO work best as ongoing maintenance of a useful website. Keep the measurements, fixes, and editorial decisions connected. Improved access and usability create a stronger site, while rankings, indexing, and rich-result appearance remain outcomes you cannot guarantee.