Audit and priorities
We review the agreed URLs, page types and available reports. You receive findings tied to actual examples, their likely business effect, the proposed next step and any investigation still needed.
Leeds · Technical SEO & Website Performance
Make the right technical changes. Keep your website useful.
Softglimmer helps Leeds businesses investigate technical SEO and website performance issues, plan the right repairs and put the agreed changes live. We work remotely from our Ranchi studio with your website, content and hosting owners. Your project can start with an audit, include implementation, or continue with an agreed review schedule.
An audit with a practical route to implementation
- 01
Find the cause
Connect the reported problem to the pages and systems involved.
- 02
Choose useful repairs
Agree priorities, responsibilities and what must be preserved.
- 03
Check the live result
Review the released pages and the customer actions they support.
An example journey, shaped around your requirements.
Choose an assessment, implementation or ongoing care.
Start with the difficulty you want to resolve and the decisions your team needs to make.
Implement selected repairs
Take agreed findings into changes to the website, templates or configuration. The scope names the content and features to retain, the people who approve the work and how the release will be checked.
Review changes over time
Where continuing care is useful, agree which pages and reports will be reviewed, how often and who handles new findings. Search reporting, content work and advertising are separate services unless included in the proposal.
Understand what happens between opening a URL and using the page.
A page can be available at its address while its important information is difficult to discover, slow to appear or dependent on an unexpected action. We follow that journey before recommending a repair. The review can cover responses and redirects, crawl and index controls, internal links, canonical signals, titles, descriptions and relevant structured data. It can also investigate the loading and rendering of the content a customer actually needs.
Performance work starts with the affected page and the conditions in which the difficulty occurs. We can examine image delivery, loading order and frontend behaviour, using comparable checks before and after an agreed change. Available real-user or Search Console reports can add context; a controlled test does not stand in for every visitor’s experience. The proposal explains the pages, devices and measurements included.
JavaScript is not automatically a search problem. Google documents a rendering stage that executes JavaScript and uses the resulting HTML. The useful question is whether the intended information and links appear in that output. We compare what the site serves, what appears without extra interaction and what the business has approved for public use. Google's JavaScript SEO guidance is linked below.
The service details appear only after a click.
Illustrative project brief: a service business publishes a page with a short introduction and a ‘View service details’ button. Clicking it fetches the main explanation, including what the service includes and the information a customer should send. The browser experience looks complete to a person who presses the button, but that does not establish that the same explanation appears in a search engine’s rendered page. The content owner first identifies which information belongs on the public service page. We then investigate how it is delivered. A suitable repair could make the approved explanation available without the extra action while retaining the button for an optional interactive tool. Acceptance checks the same text, relevant links and enquiry route after release. This is a planning example, not a claim about a Leeds client or an observed ranking result.
- 01
Identify the public explanation
Agree the information a visitor should be able to read at this URL.
- 02
Inspect its delivery
Compare the response, rendered content and button-dependent state.
- 03
Review the repaired page
Check the retained explanation, optional interaction and enquiry route.
Illustrative content-loading review, shaped around the actual website.
Give each kind of information the right place.
The example needs a content decision as well as a technical change.
| Information | Why it matters | Decision to make | Result to review |
|---|---|---|---|
| Public service explanation | What the business intends every visitor to understand. | Identify the approved introduction, inclusions and next-step information. | The useful explanation is available at the intended service URL without requiring the button. |
| Optional interactive help | A calculator, chooser or other tool may still improve the visit. | Separate its personalised result from the essential public explanation. | The tool remains useful without becoming the only way to discover the service. |
| Links to further pages | A menu action and a discoverable destination are different things. | Review the actual destinations and how ordinary page links reach them. | Useful destinations remain reachable through appropriate links and their own maintained URLs. |
| Future content updates | A repair should not create two competing copies of the same text. | Agree which CMS field or content source editors maintain. | The owner can update the approved information without a separate manual copy becoming stale. |
Receive a clear repair plan and the work you agreed.
The proposal identifies the audit depth, implementation and follow-up so a list of findings does not become an undefined project.
01
A useful URL and page sample
Important pages, distinct behaviours and the reason each was inspected, with the review conditions recorded.
02
Prioritised findings
The affected task, the observed problem, supporting examples and what needs further access or investigation.
03
An agreed implementation scope
Selected changes, responsible owners, account or supplier dependencies and the information and features to retain.
04
Technical and loading improvements
The included template, content-delivery, asset or configuration work, with a recoverable starting point.
05
Released-page checks
A comparison of the changed public pages and important actions against the approved scope, with unresolved issues explained.
06
A practical handover
Where the changes live, who maintains them and what future monitoring or support has been agreed.
Check the explanation itself, not just a working button.
For the illustrative page, write down the approved service explanation before changing how it loads. Compare that text with the response and the rendered page. Google’s lazy-loading guidance says Search does not interact with pages, so a successful manual click alone cannot resolve this question. The review should establish which content appears without that action and why any expected content is absent.
After the selected repair, compare the explanation and links again. Open the public URL directly and check the ordinary desktop and mobile journeys, including the optional tool and enquiry action. Where the owner has Search Console access, its live inspection and rendered HTML can provide an additional view. An implementation check and later Google indexing remain separate observations.
The handover should also explain how an editor changes this information. Keeping the text visible by adding an unmanaged duplicate can create a different problem when one copy is updated. Agree the maintained source and verify a representative edit during the project, with any broader CMS redesign treated as a separate decision.
What shapes the estimate?
The number of working patterns
A simple service page, a filtered catalogue and an interactive application need different review cases. We agree which patterns and representative pages are included.
Who can change the platform
Access to templates, hosting and supplier-controlled features affects the available repair. We identify those owners before committing to work that depends on them.
The depth of implementation
An assessment, a focused repair and continuing care are different engagements. The estimate separates included work, outside subscriptions and any later phase.
Move from a reported issue to a checked release.
Work with the people who maintain the website and approve its information.
- 01
Share the concern
Bring affected URLs, the customer task, recent changes and any existing reports. Choose the first review questions together.
- 02
Review the findings
Discuss confirmed issues, uncertainty and options. Agree the repair scope and how the useful content and actions will be preserved.
- 03
Implement and compare
Prepare recovery, make the authorised changes and compare the affected pages under the agreed conditions.
- 04
Hand over the upkeep
Explain what changed, check the editor’s relevant task and identify any continuing measurement, support or supplier work.
Bring a few pages and the question you need answered.
Send the website address, two or three examples that show the difficulty, and what a visitor is trying to do. If pressing a control reveals important information, explain which text appears and who maintains it. Include an ordinary page that works as expected, plus any recent release or platform change that may be relevant.
Tell us who owns the CMS, hosting and externally supplied features. Redacted screenshots and a short written account can help initial discussion; account access should follow the agreed review scope. Existing reports are useful when their page, date and setup are known. We will explain what can be investigated from public pages and which questions require authorised access.
Softglimmer’s studio is in Ranchi, India. Leeds is a remote service market. We agree dated review sessions using Europe/London and Asia/Kolkata, rather than assuming a fixed time difference throughout the year. Written priorities and named content and technical owners keep decisions moving between those sessions.
See how real service information is presented.
KMS Consultancy’s website organises a complex service catalogue into pages and an enquiry journey. It is a real studio website reference for discussing useful public information. The content-loading example above is illustrative and is not presented as a KMS audit or a Leeds project result.
ContentCompliance
StructureService pages
ActionEnquire
Questions before starting the review.
Do we need to replace our current website?
That depends on the cause and the access available. A template, loading rule or configuration repair may be enough. A platform move needs a separate reason, preservation plan and estimate; it is not the default result of an audit.
Can we keep interactive tools and expandable sections?
Yes, where they help the visitor. In the worked example, the decision is which information should be available without an extra action and which result genuinely belongs to the tool. We review the actual delivery rather than treating every JavaScript feature as a fault.
Can you start without Search Console access?
We can inspect public responses, links, content and relevant rendered behaviour. Property reports can answer additional questions about search-engine processing. The scope explains what has been checked and what needs an account owner’s authorised access.
How will we know which fixes are worth doing?
Findings should explain the affected user task, the observed issue, the proposed change and its dependencies. We review priorities with you before implementation, and check the agreed released pages afterwards. Wider content work and advertising have their own scope.
Will the work guarantee Google rankings?
No. We can agree and check technical work on the website, then review available search reports over time. Google determines crawling, indexing and rankings; a technical release or sitemap entry does not guarantee those outcomes.