Technical SEO guide: from crawlability to structured data for organisations

Technical SEO is the infrastructure work that lets search engines crawl a site without obstacles, index the right pages and understand their content correctly. For organisational websites, its foundations are crawlability, a sitemap, canonical URLs, correct redirects, speed, structured data and properly marked-up language versions. However good the content is, if this layer is broken the pages will not reach the place they deserve in search.

What is crawlability and how do you ensure it?

Crawlability means that search engines' automated crawlers can reach the pages on a site and read their content. If a page receives no links, only opens after a form is submitted or loads its content late through scripts running in the browser, the crawler may not find it or may see it as empty. On organisational sites, the most common problem is that important pages are linked not from the menu but only from inside a single announcement.

The robots.txt file at the root of the site tells crawlers which sections to stay out of. A one-line mistake in this file can remove the entire site from search; a common accident is a blocking rule added for the test environment being left in place when the site goes live. Likewise, the no-index tags on pages belong on the pre-launch checklist.

To strengthen crawlability, review the following points regularly.

• Every important page can be reached within a few clicks from the menu or from related pages.
• The page's main content is present in the HTML delivered by the server, before any script runs.
• Links use real link elements rather than being hidden behind buttons that only respond to click events.
• Test and development environments are closed to access, and no blocking rule has been left behind on the live site by mistake.
• Broken internal links are scanned for and fixed periodically.

How do you set up a sitemap and canonical URLs?

An XML sitemap lists the pages on a site that should be indexed, telling search engines which addresses matter and when they were last updated. Hand-made sitemaps go stale quickly, so the sitemap should be generated automatically by the content management system and update itself whenever a page is published or removed. It should contain only addresses that are actually live, do not redirect and are meant to be indexed.

A canonical URL states which address is the primary one when the same content can be reached from several. When the same page opens with and without www, over encrypted and unencrypted connections, or at different addresses because of sorting and filter parameters, search engines end up splitting the signals between them. The fix has two layers: first, all variations are permanently redirected to a single address; then every page carries a canonical link tag pointing to itself.

Paginated lists, archives and tag pages need careful canonical decisions. Pointing every page's canonical to the first page can make the content on later pages harder to find. For multi-page structures such as academic journals and news archives, giving every item its own permanent address is the most robust approach.

When and how should redirects be set up?

When a page's address changes, the old address should not simply die. Permanent moves use a 301 redirect, which tells search engines the new address has replaced the old one and helps carry the value built up by the old address over to the new page. Temporary redirects are only appropriate for genuinely temporary situations, such as a short maintenance page.

Site relaunches are the riskiest period for technical SEO. Listing every address on the old site and mapping each one to its closest equivalent on the new site in a redirect table is the only reliable way to keep the visibility built up over the years. Sending all old addresses to the homepage is an easy but harmful shortcut; search engines often treat such redirects as if the page could not be found.

Redirect chains should also be avoided. If one address goes to another and from there to a third, visitors wait longer and the crawler may give up before reaching the end of the chain. For content that has genuinely been removed, prepare a not-found page that returns the correct status code and offers visitors a search box and links to the main sections.

How does page speed affect technical SEO?

Search engines also weigh signals that measure user experience, and chief among them are how quickly a page becomes visible, how fast it responds to interaction and whether its layout shifts while loading. Speed alone does not decide rankings, but a slow page drives visitors away and raises the risk of falling behind competitors with similar content.

On organisational sites, most speed problems come from a few familiar sources: images that were never resized, scripts loaded on every page but never used, too many font files, and image areas without declared dimensions that make the page jump while loading. Serving images in modern formats sized to the screen, rendering pages on the server and limiting third-party add-ons bring a clear improvement without a major rebuild.

Judging speed by a single measurement can also mislead. A time measured on the office's fast connection and a powerful computer does not reflect the mobile devices and connections most visitors actually use. Measuring critical pages, such as the homepage, the most visited content page and the application or contact form, regularly under mobile conditions lets you see problems before visitors complain.

Technical SEO does not win rankings on its own, but it removes everything that stops good content from being found.

How do you use structured data (schema.org)?

Structured data is markup that describes what the information on a page means in a form machines can read. The schema.org vocabulary defines types such as organisation, article, event, person, FAQ and breadcrumb. The data is usually embedded in the page as JSON-LD and can open the way to richer presentation in search results, such as event dates or a breadcrumb trail.

For organisational sites, the core set is usually this: the organisation's name, logo, address and contact details on the homepage; headline, author, publication and update dates on articles; and date, venue and registration details on event pages. For organisations that publish academic work, article-level markup matters as well. In Nova JournalPort, for instance, schema.org data, the sitemap and RSS are generated automatically for every article, so editors do not have to prepare this markup by hand for each issue.

The golden rule of structured data is that it must match the visible content exactly. Marking up a rating that does not appear on the page, or a question that does not really exist, costs trust instead of earning visibility. When markup is generated at template level from fields in the content management system, it stays both accurate and sustainable.

How is technical SEO done on multilingual sites?

On a multilingual site, every language version needs its own permanent address; languages can be separated by subdirectory, subdomain or a separate domain. For organisational sites, a subdirectory is often the most manageable option, because all language versions share the trust of one domain. Forced automatic redirects based on a visitor's location or browser language can stop crawlers from reaching other language versions and lock visitors into a language they did not want.

That pages are translations of each other should be declared reciprocally on every page with hreflang markup. Language codes follow ISO standards, and each language version lists both itself and the other versions. Specifying a default version for visitors whose language matches none of them is also recommended. Having the content management system generate this markup automatically from the translation relationship, rather than by hand, prevents missing or one-way links.

When checking a multilingual site technically, the following points deserve a separate review.

• Title and description tags are written separately in each language version.
• The page's declared language matches the actual language of the content.
• Pages without a translation do not point hreflang links at a translation that does not exist.
• The sitemap includes the addresses of every language version.
• The language switcher takes visitors to the same page in the other language.

Frequently asked questions

Does submitting a sitemap improve rankings?

No, a sitemap does not improve rankings on its own. It helps search engines discover new and updated pages more quickly. On large archives and sites that add content often, it is an important tool for making sure pages are not overlooked.

What is the difference between a canonical tag and a redirect?

A redirect actually takes visitors and crawlers to another address; the old address no longer opens. A canonical tag is a hint used when a page keeps opening but its primary address is elsewhere. Permanent moves call for a redirect, parameter variations for a canonical tag.

Are script-rendered pages visible in search engines?

Search engines can run scripts, but doing so takes extra resources and time and does not always produce a complete result. Delivering critical content such as headings, main text, links and structured data as ready-made HTML from the server is the safest route for visibility.

How often should a technical SEO audit be done?

A full audit should be done at least once a year and after every major change to the site. Broken links, indexing errors and sitemap warnings can be monitored monthly through the management tools search engines provide to site owners.

Where should technical SEO work begin?

The most productive start is a short audit of robots.txt and no-index directives, the sitemap, address variations and broken links; these four areas reveal the big losses on most sites. Speed, structured data and language markup are then built on top. At Bir Web Ajans we build this layer into the templates and content management of the sites and platforms we develop, rather than adding it later as a setting.