Technical SEO for web applications starts with a boundary: which pages should strangers find in search, and which should only work for signed-in users? A custom booking portal may have public service pages alongside customer records, appointment details and account settings. Search engines need clear access to the former; the latter need proper access controls, not clever search settings.
The practical order is to protect private data, make each useful public page reachable, check what a crawler receives, and then tidy up search signals. This applies whether the application uses ordinary server-generated pages or a JavaScript-heavy interface.
Does technical SEO differ from a normal website?
Yes, mainly because an application has different kinds of pages and may assemble them differently. A conventional brochure site usually serves public documents. A custom app can return the same outer page for many routes, change screens without reloading, or require an authenticated session before it displays anything useful.
The underlying rules have not changed. Google's technical requirements say an eligible page must be accessible to Googlebot, return a successful response and contain indexable content. Meeting these requirements does not promise inclusion in search results. An application adds decisions about visibility, rendering, session state and whether the server reports the correct response for each URL.
Consider a booking business with a public explanation of its services, a public booking information page and a customer appointment screen. The explanation should be discoverable. The booking information page may be useful in search if it answers a question independently. The customer screen should remain restricted even when someone guesses its address. Search optimisation should never convert a private feature into a public page.
Should logged-in pages be indexed?
No. A genuine account page, booking record, invoice or staff-only screen has no useful role as a public search result. Require authentication and check authorisation for the particular record or action on the server. OWASP's authorisation guidance explains why hiding a screen in navigation does not restrict direct requests.
Google's noindex guidance explains that a noindex directive can exclude an accessible page from search, but Google must crawl it to read the instruction. A crawler denied access by authentication cannot read a directive inside the protected page. That is fine: access restriction does the security work.
Do not publish sensitive route names in robots.txt or treat that public file as a security barrier. Google's robots.txt documentation says blocked URLs can still appear as URL-only results when other pages link to them. If confidential content has escaped, close the access flaw first, identify affected records and only then address search removal. Google's removal guidance separates temporary removal requests from permanent restriction or deletion.
Check the boundary with a private browser window and a low-permission test account. A signed-out request must not reveal customer data; a signed-in user must not retrieve another user's record by changing a URL. Repeat the signed-out check through the public hostname, since a CDN or proxy cache can serve one visitor's page to another. If either check fails, stop SEO changes, close the exposure and keep the access logs. Do not restore a known insecure release merely to make a search warning disappear. Treat the failure as a possible personal data breach: the ICO's breach guidance says that where a risk to people is likely, you must notify it as soon as possible and, where feasible, within 72 hours.
Can Google crawl a JavaScript web application?
Yes. Google's JavaScript SEO documentation, updated 4 March 2026 and checked 5 November 2026, says Google crawls, renders and indexes JavaScript pages using an evergreen Chromium renderer. Rendering is a separate processing stage. Content that appears in your browser is therefore not automatically content that Google has successfully received.
A public route can fail because its initial response is an empty shell, a required file is blocked, an unauthenticated data request fails or its content appears only after someone clicks. Google also warns that its renderer does not retain cookies or browser storage across page loads. A crawler must be able to reach the public information without borrowing a user's session.
Start with one public URL, then repeat the check for each public page template. Open it in a fresh private window, refresh it directly and compare View Source with the finished page. Then use Google's Search Console URL Inspection tool to run a live test and inspect rendered HTML, resources and errors. A successful live test means the page can be fetched and rendered in that test, not that it has been indexed or will rank.
Which fixes should come first for a custom app?
Choose work by risk and dependency. Work down this order, checking each change before moving on.
- Step 1: Establish the public/private boundary. List routes by intended audience, including shared links and exported documents. Test signed-out access and record-level permissions with harmless test data. Correct any exposure before publishing further route changes; keep a tested access path for the legitimate user.
- Step 2: Fix public URL responses. Make a public page load directly without a previous visit to the homepage. Confirm it serves its own topic and a success response, while a missing page gives a genuine not-found response. Retain the previous route mapping so a failed deployment can be rolled back.
- Step 3: Make public content readable. Check the HTML Google renders for the page's heading, explanation and navigation links. If essential text is missing, repair the data loading or serve that public content in initial HTML. Re-run URL Inspection after the change.
- Step 4: Align discovery signals. Add appropriate links, titles, canonical choices and sitemap entries only after the routes work. Confirm the published sitemap and the canonical selected by Google where indexed information is available. Restore the previous metadata or sitemap file if the change hides a wanted page.
This sequence is a decision aid, not a universal instruction to rebuild the app. A portal with only a handful of public pages may need modest changes to those routes. An application already delivering complete public HTML may need little rendering work at all.
Draw a boundary the application can enforce
Before touching templates, ask what each route represents. Use three working labels: public and search-worthy, public but not intended for search, and restricted. A service explanation belongs in the first group. A confirmation page that contains no secret but makes sense only after a transaction may belong in the second; give such pages a noindex rule that Google can crawl, because leaving them out of the sitemap does not keep them out of search. Customer data belongs in the third.
For restricted routes, keep access decisions server-side and apply them to the data, not merely the visible menu. OWASP's access-control checklist calls for default denial, limited privileges and tests of what each user may read or change. A screen can show a sign-in form while an overlooked download still exposes a file; both need checking.
Make the route inventory a small release document: intended visitor, expected response when signed out, expected response when authorised, search intention and owner of the rule. The guide to IT documentation people can actually use explains how to keep operational notes clear enough to help during a change. Record the old and new behaviour before editing access rules.
Verify the inventory against live responses using non-sensitive test records. If a previously public information page now demands a login, determine whether the rule is too broad; restore just that route's intended access, not blanket access to restricted content. For any real exposure, involve the person responsible for data protection and incident response rather than trying to conceal it with metadata.
Give each public view its own usable address
A customer can reach a page by clicking through the app while a crawler cannot discover it. Google specifically asks developers to use ordinary HTML links with an href and, for client-side routing, the browser History API rather than fragments that change the page's main content. See the History API section of Google's JavaScript guide.
For a public route, copying its address into a new browser tab should display the correct page. It should also work after a full refresh, not just after client-side navigation. A button that runs a script without a real destination may be useful for an action, but it should not be the only way search engines discover an information page.
Ask the developer to adjust routing in a test environment first, preserving existing public addresses or sending each old one to its replacement with a permanent 301 or 308 redirect. Check internal links, direct loads, mobile navigation and browser back behaviour. If old links break or unrelated pages start serving the same content, revert the route deployment and fix the mapping before changing the sitemap.
A public booking journey needs special judgement. A page explaining booking options can be search-worthy; the form's later state, a selected slot and a completed reservation usually are not independent landing pages. Do not generate search-facing URLs for every possible form combination simply because the app can display them. The test is whether a visitor arriving from search would understand the page without a previous session.
Choose rendering for the public part, not the whole app
There is no requirement to replace a working application with a fashionable framework. Google's rendering guidance recommends server-side rendering, static rendering or hydration rather than maintaining a separate bot-only rendering system as a long-term solution. The choice depends on how often the public material changes and how your system already serves it.
Static HTML works for service descriptions that change only when published. Server-generated HTML can fit a public listing whose information changes with the underlying records. Client-side JavaScript can still provide the filters, calendar interactions and signed-in experience. The important boundary is that a public search page should not need a logged-in browser or a fragile chain of actions before its main explanation appears.
Prove the need before commissioning a rendering change. Compare the initial HTML with Search Console's rendered result for representative public URLs. If both contain the meaningful text and links, changing the architecture may add risk without fixing a demonstrated search problem. If they differ, repair one route first and test content, response status, navigation and ordinary user interactions before expanding the change.
Keep the previous build available and verify caching after release. Google's JavaScript documentation warns that its rendering service can reuse old script resources despite cache headers; content-based asset filenames help distinguish updates. If the new deployment displays stale content or breaks booking interactions, switch back to the tested build and investigate the resource mapping.
Make response codes and canonical choices tell the truth
Custom routing can return a successful response for a missing record because the outer app shell loaded. Google may classify that as a soft 404. Its HTTP status guidance distinguishes successful pages from not-found and access-denied responses. Return the status that describes the resource, not merely the fact that some interface appeared.
Test a real public URL, a deliberately nonexistent public URL and a restricted test record. Record the response each receives without a session, alongside what appears on screen. Fix server routing first where you can. For a client-routed app where that is impractical, Google's JavaScript guide accepts a JavaScript redirect to a URL that returns a real 404, or a noindex tag added by JavaScript to the error view only. If a deployment accidentally marks legitimate public pages missing, roll back the routing change; monitor the affected URLs in Search Console after recovery.
A listing may be reachable through a clean address and several sorting or tracking variations. Filter and date parameters can multiply into endless combinations; Google's faceted navigation guidance explains when to block crawling of such URLs with robots.txt. Google's canonical documentation describes redirects and rel="canonical" as signals for the preferred version, not access controls or absolute commands. Select a canonical only when the content really is the same or very similar.
Check the initial HTML and rendered page for the same canonical destination. Google warns against JavaScript replacing an existing canonical with a different one, and against a noindex tag in the original page code: Google may skip rendering when it sees one, so a script that later removes it may not work. Use URL Inspection to compare the user-declared and Google-selected canonical for indexed pages; the live test cannot predict which version Google will treat as canonical. If a genuine page is being folded into another incorrectly, restore its original canonical setting and review the underlying duplication.
Use sitemaps and metadata after routes work
A sitemap is a discovery aid, not a permission list and not a request to index everything the application can produce. Google's sitemap instructions say to include full, preferred URLs that you want in search results. Leave private records, temporary steps and unwanted parameter variations out. Review the actual generated file, rather than assuming its contents match the site's menu.
On each search-worthy public page, use a unique title and meta description that match the visible content, and check that they change when the app moves between routes without a full reload. A canonical can help with genuinely duplicate addresses. Structured data is optional and should describe what the visitor can see; Google's structured-data policies do not permit markup that misrepresents the page, and valid markup does not guarantee a special search display.
Release these changes on a small sample first. Confirm that the sitemap contains only intended public canonical addresses, that titles do not repeat across unrelated pages and that the rendered content still matches each description. If a template update applies the same unwanted directive everywhere, restore the previous template and regenerate the sitemap after the corrected release.
Check the release, then monitor what Google actually saw
Before release, save the existing route and metadata configuration, have a known way to redeploy it and test a restore rather than assuming the backup is usable. The principles in verifying backups through recovery tests matter here because a search change can share a deployment with customer-facing application code.
Run a short acceptance pass with a public information route, a public route reached directly, a nonexistent address and a restricted test record. Test without a session, then with the appropriate test account. A passing SEO check cannot compensate for failed booking, payment or account permissions; stop the release and revert the offending change if core behaviour has regressed.
After the release, inspect a representative public URL in Search Console. Compare the live test with the indexed report, noting that Google says the latter reflects its last crawl rather than whatever you deployed after that crawl. Review the Page Indexing report for accidental exclusions and the selected canonical for indexed pages. A sitemap submission or indexing request is a prompt, not proof that Google has accepted a page.
Keep a brief change record with the URL, intended audience, former response, new response, test outcome and rollback reference. That makes a later indexing issue easier to trace without guessing which unrelated release caused it. If indexing does not change immediately but live tests are sound, continue observing rather than repeatedly altering working routes.
Make a small, reversible first change
Start with a route inventory and one representative public page. If you need an independent written assessment before a developer changes live routing, the technical SEO services page explains that option. Good technical SEO for web applications means public information is accessible to search engines while private application data stays private.