SEO Specialist interview questions and answers

Search engines work in three main steps. First is crawling: bots like Googlebot discover pages by following links and reading XML sitemaps. Second is indexing: Google renders the page, understands the text, images and structure, and stores it in a huge index. A page can be crawled but still not indexed if it is low quality, a duplicate, or marked noindex. Third is ranking: when someone searches, Google picks the most relevant and helpful results from the index using many signals, such as how well the content matches search intent, content quality and trust, links from other sites, page experience and location. Today Google may also show AI Overviews that summarise answers and cite sources. As an SEO, my job is to make sure each step works well for the pages that matter.

Search intent is the reason behind a search, what the person actually wants. The common types are informational, like "what is GST"; navigational, like "Flipkart login"; commercial investigation, like "best laptops under 60000"; and transactional, like "buy iPhone 16 online". It matters because Google ranks pages that satisfy the intent. If people want a comparison list and I offer a single product page, I will struggle to rank even with perfect keywords. The best way to understand intent is to search the keyword and study the top results: are they guides, product pages, videos or local listings? Then I create the page type and format that fits, while adding something better or more original than what already ranks.

I start with the title tag: it should be unique, clear and include the main topic near the start. Next is the meta description, which does not directly affect ranking but can improve click-through rate. Then I check the headings: one clear H1 and logical H2s and H3s that make the page easy to scan. The most important part is the content itself: does it fully answer the search intent, is it accurate, original and easy to read? I also look at internal links to and from the page with descriptive anchor text, a short readable URL, image alt text and file sizes, and relevant structured data like FAQ, Article or Product. Finally I check that the page is indexable, has the right canonical and loads quickly on mobile.

Backlinks are links from other websites to my site. Search engines use them to discover pages and as a signal that others trust or recommend the content. A good backlink comes from a relevant, trusted site, is placed editorially inside useful content, and sends real visitors. For example, a link from a respected finance news site to our tax calculator is far more valuable than 100 links from random directories. Quality matters more than quantity. I avoid buying links or joining link schemes because they break Google spam policies and are often ignored or penalised. Instead, I earn links through useful resources, original data, digital PR, partnerships and simply creating content people want to reference.

Search Console is my main source of first-party search data. In the Performance report I check clicks, impressions, CTR and average position by query, page, country and device, and I compare date ranges to spot drops or new opportunities, like queries where we rank on page two. In the Page indexing report I look for important pages that are excluded, for example due to noindex, redirects or "crawled - currently not indexed". I use URL Inspection to test a page and see how Google renders it. I submit and monitor XML sitemaps, review the Core Web Vitals report for mobile and desktop, and check for manual actions or security issues. I also export data to Looker Studio to share regular reports.

Core Web Vitals are three metrics Google uses to measure real user experience. Largest Contentful Paint measures loading, meaning how fast the main content appears, and good is 2.5 seconds or less. Interaction to Next Paint measures responsiveness to clicks and taps across the visit, and good is 200 milliseconds or less; it replaced First Input Delay in March 2024. Cumulative Layout Shift measures visual stability, and good is 0.1 or less. Google judges them using field data from real Chrome users, the CrUX report, at the 75th percentile. They are part of page experience, which is a ranking signal, but relevance and helpful content matter more. The bigger benefit is business: faster, stable pages keep visitors and convert better. I check them in Search Console and PageSpeed Insights, and use lab tools to debug.

robots.txt tells crawlers which URLs they should not crawl. It is mainly for managing crawling, for example stopping bots from wasting time on endless filter URLs. But it does not control indexing. If other pages link to a blocked URL, Google can still index it, usually without a description. A noindex tag, in the meta robots tag or an X-Robots-Tag header, tells Google not to show the page in results. For it to work, Google must be able to crawl the page and see the tag, so you should not block a noindexed page in robots.txt. I use noindex for things like thank-you pages or thin internal search results, and robots.txt for crawl control. Neither is a security tool, so private content needs a password or proper access control.

Local SEO helps a business appear when people search for services nearby, in the map pack, Google Maps and normal results. Google ranks local results on relevance, distance and prominence. I start with the Google Business Profile: correct name, categories, address, hours, services, photos and regular updates. Reviews are very important, so I help the business ask happy customers for genuine reviews and reply to all reviews, including negative ones. I make sure the name, address and phone number are the same on the website and major directories. On the website, I create clear location or service-area pages with useful local information, not just the city name swapped in. Finally, I look for local links and mentions, such as local news, sponsorships and partner businesses. I track calls, direction requests and bookings, not just rankings.

Structured data is code that describes what a page is about in a standard format, usually JSON-LD using the schema.org vocabulary. For example, on a product page it can describe the name, price, availability and reviews. It helps search engines understand the content and can make the page eligible for rich results, such as product details, breadcrumbs or event information. I add types that fit the site, like Product, Article, Organization, LocalBusiness or BreadcrumbList. The markup must match what users can see on the page, and it must follow Google's guidelines; fake reviews in markup can lead to a manual action. I test it with the Rich Results Test and monitor the enhancement reports in Search Console. I also explain to clients that it does not guarantee rich results or boost rankings by itself.

A title tag should tell people and search engines exactly what the page offers. I start with the search intent: what is the person looking for, and why would this page be the best result? I include the main topic naturally, usually near the beginning, and add something that makes people want to click, like a benefit, the year for time-sensitive content, or a price. Each page needs a unique title, because duplicate titles confuse search engines and users. I keep titles concise so the important part is not cut off, roughly 50 to 60 characters, and I add the brand name at the end where it helps. I avoid stuffing keywords, because Google often rewrites unhelpful titles. After publishing, I check CTR in Search Console and test improvements on pages with many impressions but few clicks.

I start by understanding the business goals and the most important page types. Then I crawl the site with Screaming Frog and compare the crawl with the XML sitemap and Search Console indexing data. I check status codes, redirect chains, broken links, robots.txt, noindex tags and canonicals to make sure key pages are crawlable and indexable. Next I review site structure and internal linking: are important pages within a few clicks, and are there orphan pages? I check duplicate content, hreflang if the site is international, structured data, and mobile usability. For performance I use field data from Search Console and PageSpeed Insights for LCP, INP and CLS. For JavaScript sites I compare raw and rendered HTML. Finally I prioritise issues by impact and effort and turn them into clear tickets for developers.

I start with the business: what products we sell, who the customers are, and what problems they search about. I collect seed terms from sales and support teams, Search Console, competitor sites and tools like Ahrefs, Semrush and Google Keyword Planner. I also look at forums, "People also ask" and AI answers to find real questions. For each keyword I check search volume, difficulty, intent and business value, because a low-volume keyword with strong buying intent can be worth more than a big informational one. Then I cluster keywords that share the same intent and map each cluster to one page, so we avoid cannibalisation. The output is a content plan with priorities, target pages and briefs for writers.

First I use field data from the Search Console Core Web Vitals report and PageSpeed Insights to see which metric fails and on which page templates, since fixing a template fixes thousands of pages. For LCP, I check server response time, make the hero image smaller and in modern formats like WebP or AVIF, preload it, and remove render-blocking CSS or JavaScript. For INP, I look at long tasks in Chrome DevTools, reduce or delay heavy third-party scripts like chat widgets and trackers, and ask developers to break up long tasks. For CLS, I make sure images and ads have fixed sizes and fonts load without big layout jumps. I write clear tickets with evidence, then track field data for 28 days to confirm improvement.

A good brief helps the writer create something genuinely useful, not just keyword-filled. I include the main topic and related keywords, the search intent, the target audience and what the page should achieve, such as sign-ups. I add a summary of what top-ranking pages cover and, more importantly, what they miss, so we have a unique angle. I give a suggested outline with H2s, key questions from "People also ask" and customer conversations, and point to experts, data or real examples we can include for first-hand experience. I list internal links to add, a suggested title and meta description, the call to action, and any compliance notes. I also say clearly what not to do, like stuffing keywords or copying competitors.

I start from the business goal, like leads or online sales, and show how organic search contributes to it. My main metrics are organic conversions and revenue from GA4, and clicks and impressions from Search Console, split into brand and non-brand so we see real growth beyond people who already know us. I group results by page type, such as product, category and blog, so issues are clear. Rankings are supporting data, not the headline. I also track visibility in AI Overviews and AI assistants where possible. In a monthly Looker Studio dashboard I explain the numbers in plain language with context: seasonality, algorithm updates or SERP changes. Every report ends with what we did, what we learned and what we will do next.

First I would choose a structure. For most companies, subfolders on one domain, like /ae-en/ and /ae-ar/, are easiest to manage and share authority, while country domains suit businesses needing a strong local presence. Then I would implement hreflang on every version, using correct language and region codes like en-GB and ar-AE, making the links reciprocal and adding an x-default for everyone else. Each version would have a self-referencing canonical, never one pointing to another country. Content must be properly localised, with local prices, currencies, examples and search terms, not just machine translation. I would avoid forced redirects based on IP, because Googlebot crawls mainly from the US, and instead show a banner suggesting the local site. Finally, I would set up Search Console for each section, build local links and track performance per market.

Category pages often have the biggest SEO potential in ecommerce because they match broad commercial searches like 'women's running shoes'. I start by mapping categories and subcategories to real search demand, sometimes creating new landing pages for valuable filter combinations. Each category gets a unique title and H1 that match intent, plus short helpful content, like key buying tips, placed so it does not push products down too far. I make sure the internal linking is strong, with clear navigation, breadcrumbs and links from related categories and guides. Faceted navigation needs control, so low-value filter combinations are not crawled, while pagination uses normal crawlable links. Page speed and Core Web Vitals matter a lot on product-heavy pages. Finally, I add breadcrumb structured data and keep out-of-stock handling sensible so pages do not empty out.

I start with research on the audience's questions and problems, using Search Console, keyword tools, sales and support teams, and forums. Then I choose a few pillar topics that match the business's products and expertise. For each pillar, I map subtopics to separate pages, making sure each page has a distinct intent so pages do not compete with each other. The pillar page gives a strong overview and links to the detailed pages, and each detailed page links back and to related pages. The content must be genuinely helpful and show first-hand experience and expertise, for example with real examples, data or expert input, because thin content will not perform. I publish in a logical order, starting with the most valuable topics. Finally, I measure performance per cluster and regularly update, merge or remove pages that are outdated or weak.

I focus on earning links by creating things people genuinely want to reference. That might be original research, such as a survey or analysis of our own data, a free tool or calculator, or expert commentary on industry news. Then I use digital PR to pitch the story to relevant journalists and bloggers, with a clear angle and ready-made charts or quotes. Over time I build relationships with writers in our space, so they come to us for expert input. I also look for unlinked brand mentions and ask for a link, and for broken links on relevant sites where our content is a good replacement. I avoid paid followed links, private blog networks and mass link exchanges, because they break Google's spam policies. I judge success by relevance and quality of linking sites, plus referral traffic and brand coverage, not just link counts.

I start by crawling the site to build a full inventory of posts with titles, word counts, dates and internal links. Then I combine this with Search Console clicks and impressions, GA4 engagement and conversions, and backlink data. With that, I put each post into a group. Posts that perform well are kept. Posts with potential, like many impressions but low clicks or outdated facts, get updated. Several weak posts on the same topic are merged into one strong page, with 301 redirects from the old URLs. Posts with no traffic, no links and no business value, which are not worth improving, are removed with a 404 or 410, or noindexed if users still need them. I prioritise the work by potential traffic and business value. After the changes, I track indexing, rankings and traffic for the affected sections.

First I confirm the drop is real. I compare GA4 with Search Console, because a broken analytics tag or consent change can look like a traffic loss. Then I segment the drop by page, page type, query, device and country to see if it is sitewide or limited to one section. If it is sudden and sitewide, I check for technical causes: a recent deployment, robots.txt changes, noindex tags, canonical or redirect mistakes, server errors, or a JavaScript change hiding content. I use URL Inspection on key pages. If technical checks are clean, I look at dates of Google core or spam updates, manual actions, and whether the SERP changed, for example new AI Overviews. I share a short update with stakeholders early, then a clear root cause and recovery plan.

Migrations are high risk, so I join the project early. First I benchmark current traffic, rankings, conversions and top linked pages, and suggest splitting changes into phases if possible, since changing URLs, CMS and design together makes problems hard to isolate. I build a full inventory of URLs from crawls, sitemaps, analytics and backlink tools, and create a one-to-one 301 redirect map. On staging, which is blocked from indexing, I crawl the new site, test redirects, check content and metadata parity, internal links, canonicals, structured data and JavaScript rendering. On launch day I verify redirects, robots.txt, sitemaps and Search Console. After launch I monitor crawl errors, indexing and traffic daily, fix issues quickly, and agree a rollback plan in advance.

I would accept that simple factual queries will send fewer clicks, and shift effort to areas where we can still win. First, content with real unique value: original research, expert opinions, first-hand testing and tools that AI answers cite and cannot fully replace. Second, clear structure with direct answers near the top, good headings and structured data, so both search engines and AI systems understand the page. Third, brand building: mentions, reviews and coverage across trusted sites, because AI systems lean on widely recognised sources. Fourth, focus on commercial and transactional queries, where users still click to compare and buy. Technical basics still matter, since AI search depends on crawlable, indexable content. Finally, I would update reporting to track AI citations, branded search growth and conversions, not only clicks.

First I would talk to the developers and product manager to understand their goals and constraints, instead of assuming they do not care. Often SEO tickets are vague or seem low value. So I would rewrite them: each ticket explains the problem, the evidence, the expected business impact, for example "category pages bring 30% of revenue and 400 are not indexed", and clear acceptance criteria. I would split big tasks into small ones and suggest quick wins that fit into current sprints, like template fixes. I would also try to add SEO checks into their release process so issues do not come back. When a fix ships, I share the results publicly and credit the team. If an issue is critical, I escalate with data through the product owner, respectfully.

I would thank them for the clear goal, then be honest. "CRM" is extremely competitive, dominated by brands like Salesforce and HubSpot with huge authority, and the intent is mixed, so ranking first in three months is not realistic, and no ethical SEO can guarantee rankings. Then I reframe around what they really want: qualified leads. I would show data on competitor strength and suggest more specific, high-intent keywords where they can win sooner, such as "CRM for real estate agents in India" or comparison and alternative pages. I would propose a phased plan: technical fixes and quick wins in the first months, targeted content and link earning next, with milestones like non-brand clicks, demo sign-ups and visibility for the broader term over 12 months.

First I read the manual action details in Search Console to see whether it affects the whole site or specific pages, and I check the examples Google gives. Then I export backlinks from Search Console and tools like Ahrefs or Semrush and audit them, looking for paid links, link networks, keyword-stuffed anchor text and spammy directories. I talk honestly with the client about any past link buying, because the reconsideration request must explain it. I contact site owners to remove the worst links and keep a record of all outreach. For links that cannot be removed, I create a disavow file at domain level where appropriate. Most importantly, the client must stop the practice. Then I submit a reconsideration request explaining what happened, what we did and how we will prevent it. If it is rejected, I review the feedback and continue the clean-up.

I would ask for server-side rendering or static generation for all important pages, so the main content, links and metadata are in the initial HTML instead of depending on client-side rendering. Navigation must use real anchor links with href attributes and clean, unique URLs, not hash fragments. Each page must return the correct status code, including real 404s instead of soft 404s, and the title, meta description, meta robots and canonical must be set in the server response. I would agree a performance budget for Core Web Vitals, paying special attention to INP, because heavy JavaScript and hydration often cause slow interactions. We need structured data, XML sitemaps that update automatically and a correct robots.txt that does not block scripts. Finally, I would test on a staging site with a crawler and Google's URL Inspection, and plan redirects if URLs change.

I would explain that Google does not ban AI content; it rewards helpful content however it is made. But mass-producing pages mainly to rank, with little original value, can fall under the scaled content abuse policy and hurt the whole site. So the question is not how many articles we can publish, but whether each one is the most useful result for its search. I would suggest using AI where it adds speed, such as research, outlines, first drafts and updating old posts, while experts add first-hand experience, original data and judgement. Every article needs human editing and fact-checking, especially in areas like health or finance. I would start with a pilot of a smaller number of topics, measure indexing, rankings, engagement and conversions, and compare with our usual content. Then we scale only what proves its quality and value.

I start with the target keyword set, its monthly search volume and our current positions from Search Console and rank trackers. For each keyword, I estimate realistic target positions, then apply a CTR curve, ideally based on our own Search Console data, adjusted down where AI Overviews, ads or other SERP features take clicks. That gives estimated extra clicks. Then I convert clicks to conversions and revenue using our actual organic conversion rates and order values, or lead values from the CRM. I present conservative, expected and optimistic scenarios rather than one number, and I state the key assumptions clearly. I also show the timeline, because SEO often takes several months to show results, and compare the expected return with the cost of the work. After launch, I track actual results against the forecast and update it, which builds trust for future proposals.

First I would get at least a few weeks of server or CDN logs and filter them to verified Googlebot, using reverse DNS or Google's IP ranges, because many bots fake the user agent. Then I would analyse which sections and page templates Googlebot crawls, how often, and which status codes it receives. On large ecommerce sites I usually find crawl waste: huge numbers of hits on filter and sort parameters, internal search pages, redirect chains or old URLs. Next I would compare the crawled URLs with our list of important, indexable pages, such as key categories and in-stock products, to find pages Google rarely or never visits. Fixes might include robots.txt rules for low-value parameters, better internal linking to deep pages, cleaner sitemaps, and fixing 5xx errors or slow responses. I would keep monitoring logs to confirm Googlebot shifts its attention to valuable pages.